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Network Games 



A Htwork gaming will recreate the 
Wk :omputer entertainment indus- 
1% :ry and revitalize the cartridge 
I » market. W ithin a few years, 
I » inline gaming will be the domi- 
I • lant form of computer recre- 
I 1 ation. Normally, I preach the 
I whorizon of predictability"— 
beyond which nothing can be said with 
certainty— is an astonishingly short 14 to 
16 months away. Anyone who predicts 
beyond that is like a six-year-old on a 
whale-watching expedition, shouting, 
'There's a whale," and pointing randomly 
And network gaming isn't going to be a 
major force in the next 14 to 15 months 
(although by the end of 1996, early 
adopters will play exciting new games); it's 
more likely to happen within 5 years. But 
we're on the eve of adopting several tech- 
nologies, which point to explosive growth 
in multiplayer gaming. 

First and foremost, the world is get- 
ting wired. In other words, everyone will 
be able to at least "get to" game servers 

Second, 3D chips will take the mar- 
ket by storm. I n the cartridge market, one 
need only look at the new generation of 
machines to be impressed, while the desk- 
top video card market has been fairly bland 
for several years as the limitations of W in- 
dows 3.1 overshadowed improvements in 
card technology, color-depth, and onboard 
RAM . The past 14 months have seen an 
unprecedented boom in the high-end of 
the desktop 3D market— the technology 
gap Silicon G raphics has enjoyed for years 
has rapidly shrunk and, according to some, 
disappeared in the low-workstation price 
points. Consumer 3D technology is poised 
to enter the market, and card manufactur- 
ers will enjoy perfect timing as 3D graphics 
upgrades become the upgrade of the year. 

Third, network connections will add 
voice capabilities. I don't think DVSD and 
A SDL modems will enjoy the explosive 



growth I predict for 3D video boards, but 
they'll become popular with niche, moti- 
vated buyers. Initially, this motivation will 
come from network- based telephony and 
multiplayer gaming of existing games. 
M ore importantly, ISDN should fill out 
the niche without jeopardizing bandwidth. 
ISDN, however, remains a technology 
with a considerable barrier to entry. M ost 
people will wait for the big news. Which 
will be high- bandwidth connections, cable 
modems or ATM -to- the- curb. 

T his is the fourth, and furthest out 
element prepping us for an online gaming 
explosion. I can't predict whether to buy 
stock in cable companies or ATM manu- 
facturers, since widespread availability of 
these technologies is years away. T he 
bandwidth numbers of these technologies 
are incredible— more than enough to make 
believable the wildest ideas of network- 
based applications. If these technologies 
are really able to deliver and transmit sever- 
al megabits per second, a revolution as 
profound as the arrival of the desktop PC 
will follow. 

Finally, why did I say that network 
gaming will revitalize the cartridge market? 
Let's talk about the Java terminals comput- 
er magazines say have no market. They're 
right to say people won't download word 
processors and work on their resumes with 
an Internet terminal rather than their 
$3,500 home PC; kids will download the 
latest version of "Java Warriors," to their 
cartridge machines. Sun's second-tier 
M icrojava chip is scheduled for the first 
quarter of 1997, with a unit price of $25 to 
$50. Can an Internet terminal be built for 
$500? Let's see— a Java game cartridge, 
hooked up to a cable modem, on a Sony 
PlayStation or Ultra64. Do you think it 
would sell? ■ 

Larry O'Brien 
Editorial Director 
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Applesauce 



Alex Dunne 

^osewho do not 
learn from history are 
doomed to repeat it, At 
Apple, Amelio's got his 
work cut out, Let's 
jump in the time 
machine and look 
back on Spindler's 
reign. 



f you had been at M acworld in San 
Francisco earlier thisyear, you prob- 
ably wouldn't have seen any overt 
signs that Apple was auguring in. 
M ore than 70,000 people attended 
the show, you had to strong-arm 
your way through the crowds, and 
everyone seemed upbeat (even actor 
G regory H ines of "W hite N ights" and 
"H istory of the World, Part l"fame, who 
I saw on the show floor). But the bustling 
crowds and high energy at M acworld hid 
a frightening fact: Apple is in serious 
financial trouble, and despite H ines pres- 
ence, there's no white knight coming to 
the company's rescue. 

T he latest rumor before we went to 
press was that Sun M icrosystems was to 
acquireApple. Sun joins an illustrious list 
of would-be suitors over the past few 
years. Unfortunately, even if this merger 
rumor had panned out, it probably would 
have been too little, too late. A pple's mis- 
management has tal<en it to the brinl<. 
P ursuits such as N ewton, eW orld, pen- 
Doc, Kaleida Labs, and Taligent have 
drained the company's coffers and divert- 
ed its attention away from its bread-and- 
butter computer business, which has suf- 
fered as a result. 

N ow it appears that the W Intel 
juggernaut has more than enough 
momentum to carry it past any would- 
be competition. Lool<ing bacl< a few 
years, it all seems so clear now how mis- 
guided Apple's strategies were. Let's set 
our way-bacl< machine to the beginning 
of 1993 and roll tape. 

1993: Spindler takes over. 

January. Apple is enjoying outstanding 
sales of the immensely popular Power- 



Boole notebook computers. However, 
because A pple is cutting its hardware 
prices to compete with the free- falling 
prices of W indows- based computers, 
first fiscal quarter earnings are actually 
down compared to 1992. 

M arch. Second quarter results are 
again flagging, again due to price cuts. 
In response, Apple contemplates cut- 
ting its operating expenses through 
reorganization. 

M ay. CEO John Sculley announces 
Apple is "shifting its focus away from 
hardware and concentrating on the sys- 
tem software that controls computers 
and communications, and even online 
information services." David Coursey of 
PC Letter calls the company "immensely 
confused." 

June. Sculley steps down after a 
ten-year stint as CEO, and the board 
names president M ichael Spindler to 
take his place. Spindler is charged with 
navigating the company out of its finan- 
cial trouble and taking a greater hands- 
on role in management. Sculley stays on 
as chairman. 

July. Third quarter results send 
shock waves through the industry. A pple 
reports a whopping $188 million loss, its 
largest-ever quarterly loss, due mostly to 
a $321 million restructuring. On the 
same day, A pple declares that 2,500 
employees (over 15% of the company) 
will be laid off. A nalyst D oug Kass, pres- 
ident of the Viewpoint G roup consulting 
firm, sums it up when he tells the San 
F randsoD Chronide; "A well-run company 
shouldn't have to reorganize every couple 
of years. To bring out a ground-breaking 
product like the PowerBook and then 
stumble leaves us with little confidence 
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that they can navigate a new market with 
N ewton. . . ." H ow prescient. 

August. At ivi acworld in Boston, 
A pple unveils the N ewton, its $700 
dyslexic "personal digital assistant." 
Apple insists it is not betting the compa- 
ny on N ewton. G ood thing. 

September. Apple announces it will 
license necessary technology to other 
companies interested in manufacturing 
M acintosh clones, reversing a decade of 
closed-architecture strategy. Donald 
Stricl<land, Apple's vice president for 
licensing, hints to the C hronide that a 
big player in the hardware industry will 
be among the clone makers. 

October. Robert Puette, president of 
Apple USA, leaves a day before fourth 
quarter results are announced that show 
profits down 97%. Apple's inventory of 
unsold products stands at an unhealthy 
$1.5 billion. Ian Diery, executive vice 
president of Apple's Personal Computer 
Division, takes over for Puette. At Sey- 
bold, D iery explains that A pple is central- 
izing its forecasting procedures and moni- 
toring aspects of sales to prevent product 
shortages and overproduction. Sculley 
leaves his position as chairman and is 
replaced by Apple cofounder M ike 
M arkkulajr. 

November. Dell Computer, AST 
Research, and Compaq allegedly are 
approached about licensing the M ac OS 
but all refuse Apple's offer. 

1994: Trimming Down, 
But Losing Focus. 

January. Apple's online service, eWorld, 
debuts at M acworld in San Francisco. 
Gary Arlen, a media researcher, quips, 
"U niess A pple has something new to 
offer, it'll be tough to hold its own 
against the existing players." eW orld is 
priced much higher than competing 
online services, such as America Online 
and CompuServe. Earnings for the first 
quarter are down 75% by the ongoing 
price war in the hardware industry, 
despite record shipments of M acs. 

F ebruary. A pple unveils its own ver- 
sion of a TV set-top box for delivering 
movies and services like electronic shop- 
ping. The box, which will sell at about 
$300, gets shrugs from analysts. 



M arch. Apple launches its line of 
PowerM acs, which are driven by M otoro- 
la's PowerPC chip. T he launch at L incoln 
Center in New York is the most antici- 
pated event since Apple launched the 
M acintosh a decade earlier. Oracle CEO 
Larry Ellison considers buying Apple 
with help from convicted junk-bond king 
M ichael M liken. Go figure. 

April. Gaston Bastiaens, head of 
Apple's Personal Interactive Electronics 
(PI E ) division responsible for the N ew- 
ton, is fired because of the product's dis- 
mal sales. T he A pple PI E division 
employees reportedly break into cheers 
upon hearing the news. Spindler blames 
poor N ewton sales on retailers who 
weren't doing enough to explain the 
N ewton to customers. 

M ay. R umors fly that A pple is try- 
ing to persuade IBM to produce M acin- 
tosh clones. Ten years earlier, IBM was 
portrayed as Big Brother in Apple's 
famous television commercial launching 
the original M acintosh. H ow times 
change! 

July. System 7.5 is launched. Ana- 
lyst Bruce Lupatkin of H ambrecht & 
Ouist says the operating system is "a 
nice, evolutionary extension, but there is 
nothing dramatic about it." 

September. Apple starts an aggres- 
sive campaign to license its operating 
system, targeting major U .S. companies. 

October. AT&T holds talks with 
Apple about a possible takeover, accord- 
ing to the Chronicle. M otorola is also 
mentioned as a possible contender for 
A pple. N one of the companies com- 
ment. Spindler reportedly talks with 
IBM about securing an equity invest- 
ment in Apple and possibly leasing the 
M acOS. 

November. Apple, IBM, and 
M otorola team up to design a common 
machine. Two weeks later at Comdex, 
IBM backs away from the alliance, citing 
concerns from its corporate customers 
who think IBM might be wavering in its 
support for OS/2 by working closely 
with Apple. 

December. Power Computing, a 
company with only 20 employees, and 
Radius announce that they will be the 
first companies to sell M acintosh clones. 



1995: The Downward Spiral 

January. Information Week reports that 
Oracle, Philips Consumer Electronics, 
and M atsushita are about to undertake a 
hostile takeover of A pple. racle is 
apparently interested in the M acOS and 
Taligent software, while Philips and 
M atsushita will split the hardware busi- 
ness. All parties deny the rumor, and 
A pple reiterates it is not for sale. 

Apple posts record revenues of 
$2.83 billion for the first fiscal quarter, 
due largely to outstanding Power M acin- 
tosh sales and cuts in operating costs. 

February. The Supreme Court 
denies Apple's appeal in a seven-year old 
lawsuit against M icrosoft. The suit 
accused the Redmond company of copy- 
ing the M acintosh graphical user inter- 
face, dating back to M icrosoft W indows 
2.03. Apple dashes off a letter to U.S. 
D istrict Judge Stanley Sporkin, warning 
Sporkin that M icrosoft has bullied 
Apple and can't be trusted to abide by 
the proposed antitrust settlement. Gates 
chastises Spindler for Apple's legal tac- 
tics, and denies Apple's allegation that 
M icrosoft threatened to stop producing 
software for the M acintosh. 

M arch. Spindler acknowledges 
Apple is having problems filling orders 
for Power M acintoshes because of poor 
planning and component shortages. 
Salomon Bros, cuts its earnings esti- 
mates as a result, lowers its rating on 
Apple to underperform, and the compa- 
ny's stock drops 8% in one day. 

April. Spindler announces another 
major shakeup at Apple. Four divisions 
are merged into two, and veterans D avid 
Nagel and Dan Filers are given leader- 
ship over the divisions. Ian Diery, 
Apple's executive vice president and 
head of the PC H ardware division, 
resigns. 

M eanwhile, rumors swirl that 
C anon I nc. is in talks with A pple about 
acquiring the company. 

M ay. Apple Chief Financial Officer 
Joseph Graziano states that Apple is not 
for sale and that the impact of licensing 
the M acOS will be "modest" during 
1995. Radius announces it has to wait 
until fall to ship its M acintosh clones in 
large quantities due to a shortage of parts. 
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June. eWorld celebrates its first 
birthday. W ith a subscriber base of only 
80,000, prices slightly higher than com- 
peting services, and no internet connec- 
tions other than e-mail, the service is 
described by one analyst as, "America 
Online with nicer artworl<, no content, 
and no users." 

July. Frank Seiji Sanda, the presi- 
dent of A pple's successful Japanese oper- 
ation, quits unexpectedly. Apple's third 
quarter results fall short of expectations, 
as earnings are down due to supply prob- 
lems. M arkkula sells 400,000 shares of 
his A pple stock. A pple declines to 
explain why. 

August. Apple tries to dismiss the 
hype surrounding the launch of Win- 
dows 95 with their "been there, done 
that" slogan. Senior Apple executives 
sell hundreds of thousands of more 
shares of Apple stock. In two months, 
M arkkula has pared his stake in Apple 
by $44.1 million. 

Apple executives have quietly 
drawn up "golden parachute" agreements 
for themselves, entitling management to 
large payments in the event they lose 
their jobs or are demoted following a 
takeover. Spindler's payout alone could 
be worth as much as three times his 
salary and bonus, or around $3 million. 

September. In one day, the compa- 
ny delivers a double-whammy of bad 
news. First, it advises investors that its 
earnings for the fourth quarter will be 
"well below" W all Street estimates. Sec- 
ond, it announces that it has stopped 
shipping its new PowerBook 5300 
models, due to problems with their 
lithium ion batteries that have a ten- 
dency to overheat and ignite. 

Following this announcement, 
business columnist H erb G reenberg 
slams Spindler. "Yesterday, Apple 
appeared to be spinning out of control, 
but Spindler was nowhere to be found. 
On a day when he should personally 
have been reassuring investors, the press, 
and customers that all is well, he was out 
of his office, and he wasn't expected to 
return until M onday. Terrible timing." 

A pple lays out plans to revamp 
eW orld, by offering sections of the ser- 
vice to users of the W orld W ide W eb. 




and allowing eWorld subscribers access 
to the web from within the service. 
eWorld, still lagging far behind other 
services with only 115,000 members, is 
in trouble. 

An increasingly skeptical press and 
analyst community speculates whether 
Spindler is going to get the boot from 
Apple. M arkkula remains strongly 
behind Spindler, however, and there's 
little chance that the board will act to 
fire Spindler without the Chairman's 
say-so. 

October. Joseph Graziano, Apple's 
C FO for six years and a member of the 
board, leads efforts within the board to 
remove Spindler, reports the Chronide. 
According to unnamed sources, 
Graziano says, "Either Spindler goes 
and the company is sold, or [I] will 
quit." A pple's board meeting held there- 
after produces no changes, and 
G raziano announces his resignation, cit- 
ing "differences of opinion" with 
Spindler as the reason. 

Commenting on Graziano's depar- 
ture, Kimball Brown of Dataquest tells 
the San Jose M ercury N ews, "T he most 
dangerous job in high tech today is the 
N 0. 2 spot at A pple, because Spindler is 
not comfortable sharing power." 

Approximately a week later, Apple 
undergoes another reorganization. I n the 
shakeup, the media group, which used to 
report to senior vice president Dan Fil- 
ers, now reports directly to Spindler. 

November. Dan Filers resigns. 
Apple and IBM 's joint venture, Kaleida, 
shuts down. 




D ecember. A pple announces it will 
probably lose money in the first quarter, 
citing its inability to meet production 
demands and its shrinking profit margin. 
A pple's stock drops 15% in the two days 
following this announcement, and as a 
result Standard & Poor's Corp. puts the 
company's debt on credit watch for pos- 
sible downgrading. 

Apple and IBM end their partner- 
ship in Taligent, an effort to advance 
object-oriented software technology. 
Taligent becomes a subsidiary of I BM . 

1996: Chapter 11? 
Acquistion? Your Call 

January. A busy month indeed. At M ac- 
world, Apple makes no major news 
announcements and holds no news con- 
ferences for the press. Spindler doesn't 
even make an appearance at the show. 

Another exodus of Apple executives 
takes place, as a stream of vice presidents 
depart: B arbara K rause (VP of C orporate 
C ommuni cations), J im G roff (V P of 
Education M arketing), Peter Friedman 
(VP and General M anager of Internet 
Sources), Keith Fox (VP of the H ome 
Division), and Don Strickland (VP of 
Business and G overnment Sales). The 
number of high-ranking executives that 
have left in the past year stands at 14. 

Apple reveals that it lost $60 mil- 
lion during the traditionally strong 
Christmas quarter and that its profit 
margins have hit a record low of 15% — 
despite further price cuts. Apple's mis- 
judgment of demand for the more pow- 
erful Power M acintoshes resulted in a 
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backlog and lost sales during the holiday 
season. A pple announces it will undergo 
a huge restructuring, cutting 1,300 jobs 
at the company, and jettison unprofitable 
businesses. 

Radius sells its clone- making busi- 
ness to U max D ata Systems. L inley 
G wennap, editor of M iaoprocessor Report 
opines to theChronide, "It sounds to me 
as if U max and Radius decided it wasn't 
worth having both of them [making 
clones] and that they'd rather combine 
their efforts... [the demand for clones] is 
not taking off as quickly as people 
thought it would." 

The Wall Street Journal reports that 
Sun M icrosystems is in negotiations to 
acquire Apple, and Sun's stock falls 9%. 
Apple denies the rumor, states that it is 
not for sale, and says that Spindler has 
the full support of the board. 

M arkkula announces that Spindler 
is suffering from health problems and 
says Spindler's role at the company 



"could be lessened or redefined." Some 
speculate this may be a way to ease the 
CEO out of the company gracefully. 
Others demand M arkkula's resignation, 
blaming him for the company's travails. 

At the annual shareholder's meet- 
ing, insults fly at Apple management. As 
Spindler and M arkkula sit in front of 
500 investors and employees, there are 
calls for resignations, accusations of 
incompetence, and demands for im- 
provement. Employees complain about 
the loss of competent managers. One 
employee almost breaks down crying, 
explaining that though he loves Apple, 
he's considering job offers from other 
companies. 

February. Apple's board announces 
that Gilbert Amelio, former president 
and CEO of National Semiconductor, 
will replace Spindler and take over the 
Chairman position from M arkkula. The 
appointment signals to the world that an 
acquisition by Sun M icrosystems is off. 



Where to From Here? 

T hat's the saga as we go to press. W hat- 
ever its future, major changes will contin- 
ue to rock the company. Some have sug- 
gested that by spinning off its hardware 
business and focusing solely on its more 
profitable software business, A pple would 
insulate itself from the cutthroat hardware 
price wars which have caused the compa- 
ny's profit margins to dive. It's not a bad 
idea, but I doubt Apple will consider it, 
given their strong feelings about keeping 
the company intact. 

This past January, one M acworld 
attendee was resigned to all of the 
depressing reports about Apple: "M ost 
M acintosh people are used to hearing 
bad news all the time." Unfortunately, 
the worst may be yet to come. ■ 

While Alex D unne is allegedly a M ac 
fan, coworkers have never seen him use 
one. Contact him via e-mail at 
76702. 1142@oDmpu5ervea)m. 
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s Aren'-t 
J ust for Kids 
Anymore! 




SATISFACTION GUARANTEED! 
Dear Editor: 

Great issue! Particularly, "The Play's The 
Thing" by Barbara Hanscome (Dec. /Jan. 
1996). I especially enjoyed reading quotes 
from people like Corey Cole and Jonathan 
Knight. Please do that again and more often. I 
much prefer to hear developer people talk 
than reviewers pontificate. Insights are 
invaluable. 

Courtland Shakespeare 
Via e-mail 



EAT, SLEEP, AND DRINK GAIVIE DEVELOPER 

Dear Editor: 

My copy of Game Developer and a Snapple 
6-pack were placed on my desk by a car- 
ing individual. Before looking at the 
cover, I tried to picture what it would look 
like. "Windows 95 and Game SDK" page 62, 
"The Game Companies in and Around the 
New York Area" page 94, and "The Best 
C/C++ Compilers for Windows 95" page 105. 
I understand that the last two are recent 
requests, and you could not have possibly 
known of their existence. But the first arti- 
cle — there are 100 million Windows users in 
the world, and half of them have Windows 95. 
DOS is dead, and Windows 95 is the future. I 
just realized my opportunity, and I was hop- 
ing that you would help us lone programmers 
get a jump start with Game SDK. The last two 
requests are desperately needed by a young C 
and assembly student hoping to get a junior 



position in any game company. Help me, 
you're my only hope. 

Sean S. Whalen 
Via e-mail 

Editorial Assistant Jana Outlaw responds: 
Stay tuned: upcoming issues cover game pro- 
gramming using the Microsoft Game SDK. 
Maybe the Multimedia Careers section of the 
magazine will point you in the right direction, 
in the meantime. 

CHRIS HAS FANS! 
Dear Editor: 

Thanks for the excellent series on "3D Texture 
Mapping." In the discussion of the lines-of- 
constant-z approximation to perspective tex- 
ture mapping, Chris Hecker writes, "walls and 
floors are special cases where lines-of-con- 
stant-z are vertical and horizontal," but explains 
why it is not satisfactory in the general case. 
Maybe the best answer is to use the lines-of- 
constant-z method for the special cases of walls 
and floors, and to use the subdividing affine 
method for polygons that require the general 
solution. A closer examination of the lines-of- 
constant-z method for this very common special 
case would be valuable, although maybe it is 
too simple to fill a whole column. 

Steve Sclionberger 
Via e-mail 

Chris Hecker responds: 

Some people have vertical and horizontal ras- 
terizers and they use the vertical ones for 
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polygons that are more wall-like and the hori- 
zontal ones for polygons that are more floor- 
like. This lets you subdivide less if you're doing 
adaptive subdivision (since your "can lines" are 
closer to the lines-of-constant I, so there's 
less warp along them), but it means you have 
to integrate both rasterizers in your code. 

ANOTHER SATISFIED CUSTOMER 
Dear Editor: 

magazine is great! I don't read anything 
I but Game Developer. It's my one-stop infor- 
I mation magazine!!! 

Anonymous 



INQUIRING MINDS WANT TO KNOW 

Dear Editor: 

was reading IVliciiael J. Norton's article, 
"The Mode X-Files" in the Oct./Nov. 1995 
issue of Game Dei/e/opeA magazine and was 
wondering how I would get in contact with 
him. He stated in the article that he was 
working on a book for programming the Win- 
dows 95 SDK. I'd like to find out when he 
thinks the book will be done and who will be 
publishing it. I've been looking for a book like 
this for a while now. 

Robert Hiidebrand 
Via e-mail 

Michael Norton responds: 
I'm glad to hear there is interest in a Microsoft 
Windows 95 Game SDK book. This summer, 
Spells of Fury by Waite Group Press, will be 
reaching the shelves of your local computer 
book store. This is a culmination of a year of 
work on a very exciting project. As a profes- 
sional in the industry, I pulled together my 
resources to form a development team includ- 
ing programmers, artists, and musicians to 
put together ten fully functioning DirectX 




games. The chapters devoted to these games 
go through every inch of code with a magnifying 
glass. Source code in these game examples 
were evaluated by professionals at Microsoft 
and other software engineers in the game 
industry for accuracy 

The subject matter in Spells of Fury will sat- 
isfy a broad range of programmers, from the 
novice to the professional developer — no stone 
is left unturned. 

RRATA 

ality is job one here at Game 
eveloper magazine W e strive to 
orrect any mistakes we've made 
give any additional informa- 
hat may be helpful in providing 
you with the best product we can. ^ 

• In "Bit Blasts" (Feb./M ar. 1995), 
we told you that you could order a 
trial demo CD of Caligari'sTrue- 
Space2 for $14.95. One reader, 
David Scarbrough, informed us 
that at ftp.caligari.com, you can 
download it for free. T he directory 
is /pub/trueSpace, and the two 
files are ts2trial.txt and ts2trial.zip. 
Anonymous login is allowed; you 
can use your e-mail address for 
your password. 

• In C hris H ecker's "Let's G et to the 
[Floating] Point" (Feb./M ar. 
1996), there were two exponent 
typos. n page 20, it says, "so we 
can represent numbers as large as 
2^°°° and as small as 2^°°°." The 
second exponent should be 2"™". 
On page 22, it also says, "What 
happens if we add in 223...." The 
number should read 2^1 



Our Readers 



Hiis month, our read- 



ers search for books, 



examine lines- of- 



constant- z, and 



explain their feelings 
about Game Developer 
magazine and its 



staff, 



18 GAME DEVELOPER - APRIL/MAY 1996 



liUp;//www.iT<i.conVgdmag 



BIT BLASTS 



What's 
-the Bu 



Diane Anderson 



iat's new in the 
world of developing 
games? Check out 

products that capture 
motion, that model 
animation, and that 
accelerate it, And a 

word from the Gossip 
Lady mourning the 

loss of Eden at Apple, 



press time, we are looking forward 
to the Computer Game Developer's 
Conference. H ere are some products 
:o check out whileyou are there. 



Capture Polhemus 



Polhemus is building on its motion cap- 
ture system; U Itratrak Pro is its new ver- 
sion. It incorporates DSP technology and 
is targeted toward game developers, 
movie studios, and production houses 
involved in animation and special effects. 
It uses real-time, six- degree- of- freedom 
data from numerous sensors. D ata can be 
processed in real-time for live broadcast 
or virtual set applications. U sing the L ong 
Ranger transmitter, U Itratrak Pro pro- 
vides a working area of more than 700 
square feet. D rivers are available for most 
major software packages including 
Alias/Wavefront, Softimage, SideEffects, 
4D Vision, and Hash Animation. U Itra- 
trak Pro is an integrated system free of 
DIP switches, in a 19-inch rack mount- 
able chassis. D ata is transmitted to a 
workstation over an Ethernet or SCSI 
interface or may be saved to the hard 
drive. Pricing depends on receiver and H z 
configuration and ranges from $23,500 to 
$71,500. 

■ For more information contact: 
Polliemus inc. 
1 Hercuies Dr. 
Coiciiester, Vt. 05446 
Tei: (802) 655-3159 
Fax: (802) 655-1439 



Stealth 3D 2000 



that delivers 3D animation, 2D graphics, 
and digital video playback acceleration for 
PCs running W indows 95. It uses S3's 
triangle- based polygon rendering engine 
and features perspective- corrected texture 
mapping, bi-linear filtering, M IP-map- 
ping, alpha blending, depth-cueing, and 
fogging. It comes standard with 2M B of 
DRAM that is split between display 
memory and Z- buffer memory, but can 
be upgraded to 4M B of D RA M for bet- 
ter Z buffering, texture mapping, and bet- 
ter acceleration of 3D applications at 
higher resolutions. The Diamond Stealth 
3D 2000 features full- motion digital 
video playback at 30 frames- per- second 
by off-loading functions from the host 
CPU. The Diamond Stealth 3D 2000 
with 2IV1 B EDO DRAM for the PCI- 
bus costs $300. U pgrades, such as the 
M PEG Video Player 1100 daughtercard 
or the Diamond DTV 1100 TV tuner, 
areavailablefrom D iamond as well. 
■ For more information contact: 

Diamond l^lultimedia 

2880 J unction Ave. 

San J ose, Calif. 95134-1922 

Tel: (408) 325-7000 

Fax: (408) 325-7070 

Web: http:// www.diamondmm.com 



Softimage 3,0 



Diamond announces Diamond Stealth 
3D 2000, a new multimedia accelerator 



M icrosoft is now shipping a W indows 
NT version of its 3D modeling and ani- 
mation software, which offers the same 
animation environment as Softimage 3D 
for Silicon Graphics. Softimage 3D for 
Windows NT requires W indows N T 
3.51 (with Service Pak 2 installed), a min- 
imum of 64M B of RAM , 1GB of hard- 
disk space, and a supported OpenGL 
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Multimedia 

Shakeout Intensifies... 
Digital Pictures axed 30 people a 

couple of weeks ago. Sanctuary 
Woods drop-kicked their CEO (Scott 
Walchel<)and laid off 20 of their 100 
people. Guess Director games didn't sell 
too well over Xmas! After lulling Comp- 
ton's game people with promises that it 
would continue producing "quality" 
games, SoftKey fired virtually the entire 
game development crew. Reports are 
that the few who received offers to stay 
opted to go looking for greener pastures 
anyway. 

Deatii Threats from Disk 
Pirates in South China 

The organization that represents the 
global music industry has closed its 
Canton, China operation after staff 
learned that local CD pirates had hired 
hit-men in an imaginative anti-anti-pira- 
cy move. Hopefully U.S. and Canadian 
pirate shareware publishers won't get 
ideas! 

The Miles Drivers Boogie 

RAD Software acquired J ohn 
jviiies's AIL sound library, renamed it to 
"jviiies Sound System" and intends 
to extend it to the M ac and PowerM ac. 

Speaking of Macs- 
Apple Computer Inc. seems to be 
withering on the vine. With a huge loss 
for the last quarter and C EO Spindler's 

departure, things are looking pretty bleak 
for the hardware and software manufac- 
turer. One comment heard on the news: 
"Is the M acintosh going to become the 
next eight-track tape player? "0 ne thing 
is certain: now is a REALLY lousy time 
to be an Apple employee. Layoffs are 
looking likely. Industry analysts are pre- 
dicting up to one quarter of the Apple 
employees will receive pink slips in a 
major reorganization. The moral of the 
story here is: "Evolve or die." 

The sad part is that if Apple had had 
smarter management, they'd be in 
Microsoft's position right now. 
Instead, they're in the situation that if 
they had sold off their manufacturing 
division and invested the proceeds in 
M icrosoft stock, they would have had a 
much better year. The Gossip Lady 
predicts that Apple will be sold in the 
next year, and that they'll become a 
superb software division for a major 
hardware company. 

Wanna talk? 

E-mail The Gossip Lady at 
7 1501.3 553(gcompuserve.com. 
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graphics accelerator card. Softimage for 
Windows NT is optimized for several 
turnkey hardware configurations. Softim- 
age 3D for W indows NT costs $7,995 
through the Softimage network of VARs. 
Owners of version 2.66 or earlier can 
upgrade for approximately $1,995 (hard- 
ware not included). Softimage also 
announced support for Silicon Graphics 
lndigo2 Impact workstations, adding to 
the list of certified configurations. 



■ For more information contact: 
Microsoft 
1 Microsoft Wy. 
Redmond, Wash. 98052 
Tel: (800) 576-3846 
Fax: (206) 936-7329 
Web: http://www.softimage.com 



D laneAnderson ismanaging editor of 
G ame D eveloper magazi ne. 




BEHIND THE SCREEN 




Perspective Texture 
Mapping, Part V: 
it's Al30ut Time 



Finally! moment 
game developers have 
been waiting for, At 
long last, Chris Hecker 
unveils the denoue- 
ment of his texture 
mapping series, Wiat 
along, strange trip it 
has been, 



Ckieck the date on the Game 
la/eloper in your hands. Does 
April/M ay 1996 mean any- 
thing special? H ow about the 
same issue last year: A pril/M ay 
1995? W hat, you have no idea 
jvhat I'm talking about? That's 
understandable, since it was so 
long ago. I'll refresh your memory with a 
small quote from my column in that 
1995 issue: "M y next two articles should 
fix this lack of documentation, first by 
giving an easy- to- understand mathemati- 
cal foundation... and sample code to 
implement the naive algorithm. In the 
next article, we'll speed it up to interac- 
tive performance." 

Yes, you guessed it, the April/M ay 
1995 issue contained the first installment 
of my "two-part" perspective texture 
mapping series. N ow, a year later, we're 
finally going to finish the two part series 
with this issue, part five. T rue to my soft- 
ware engineering background, I can't 
estimate how long it will take me to do 
something to save my life. H owever, I 
feel the somewhat lengthy trip has been 
worth it. 

A Long, Strange Trip 

U nlike the first installment, this article 
will not be a journey through the elegant 
theory and math behind perspective tex- 
ture mapping. I nstead, this article will 
romp through the myriad optimization 
tricks and techniques we can use to 
squeeze every last bit of texture mapping 
performance from the Intel Pentium 
processor. While the rest of the series was 
platform independent, we have to turn to 
assembly language to get the most out of 
modern processors, and the Pentium is 



the market leader (and the C PU I know 
best). You'll still get a lot from reading 
this regardless of your chosen platform, 
but the code is specific to I ntel. H owever, 
I got a new M acintosh clone from Power- 
Computing with a PowerPC 604 chip in 
it, so don't be surprised to see a PowerPC 
version of this texture mapper at some 
later date (as soon as I get used to the 
concept of 32 general purpose registers)! 

To quickly bring us up to date, we 
decided to use a subdivided affine 
approximation to the true perspective 
curve (Behind the Screen, Dec/Jan. 
1995). This approximation uses short lin- 
ear spans with perspectively correct end- 
points to approximate the rational per- 
spective curve. I modified the DrauScan- 
Line function to do the affine subdivision 
in C -H-and the texture mapper got three 
times faster than the version with the 
divides. I uploaded a sample application 
that contains the texture mappers we 
developed so far. Of course, I was late in 
uploading it (see above comment about 
saving my life), and I apologize to anyone 
who looked and couldn't find it. The 
sample is up now though— see the end of 
this column for information on whereto 
find it. 

I can provide an overall outline for 
the optimizations we'll cover before 
going into detail. Our main optimiza- 
tions will take advantage of the dual inte- 
ger pipelines on the Pentium to imple- 
ment a very fast fixed- point linear texture 
mapper for our affine spans, and we'll use 
the floating-point unit's ability to overlap 
execution (especially those costly perspec- 
tive divides) with integer instructions to 
calculate the interpolation values for the 
next span as we render the current span. 
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forUnt Counter = 0;Counter < AffineLength;Counter++) 
{ 

int UInt = U»16; 
int Vint = V»16; 



Listing 1. The C++ Inner Loop 



♦{pDestBits++) = *(pTextureBits + UInt + 
(Vint * TextureDeltaScan)); 

U += DeltaU; 
V += DeltaV; 

} 

In addition, we'll pull a bunch of cheap 
tricks along the way to give it that extra 
l<icl<. 

Carry Me Away 

L isting 1 shows the C ++ linear inner 
loop for our OrauScanLine function. W hile 
this is better than our previous loops with 
their divides, it's still not great because 
it's doing a multiply and a bunch of shifts 
and addsfor each pixel. If we lool< at why 
it's doing a multiply, we see it's calculat- 
ing the source texture offset for each new 
coordinate, even though we're just doing 
a normal linear interpolation through the 
texture for each span. By definition, a 
linear interpolation increments by the 
same amount each step, so we can tal<e 
advantage of this coherency to speed up 
our loop. 

Let's ignore the V coordinate for the 
moment and see how we can tal<e advan- 
tage of the U coordinate's coherency. As 
you can see from the loop, the U fixed- 
point variable is shifted down to extract 
its integer portion for each pixel, which is 
then added into the texture pointer. 
H owever, since we're linear, the integer 
portion of DeitaU is going to stay constant 
for the span— always incrementing the 
integer part of U by the same amount- 
so there's really no need to l<eep the inte- 
ger portion of U around at all. If wethinl< 
only of the U increments, we can l<eep the 
source pointer at the current texture pixel, 
and we can find the next texture pixel by 
just adding in the integer part of DeltaU— 
calculated outside the loop— to the point- 
er at each step. The only problem with 
this plan is the fractional part of U plus 
the fractional part of DeitaU will some- 
times carry into the integer part of U . W e 



need to know when this happens and add 
an extra step to our source pointer. 

T his carry problem uncovers a major 
hole in C and C -H-from the standpoint of 
integer optimizations: there's no carry bit. 
I n other words, in assembly language, it's 
trivial to know when two added numbers 
overflow because the carry bit will be set, 
but in C -H- there's no way to know with- 
out doing a bunch of cumbersome tests. 
So, in pseudocode, we want to do this: 

UFrac += DeltaUFrac 
pTexture += DeltaUInt + Carry 

W here the variable Carry is set to if 
the fractional addition didn't carry into 
the imaginary integer part (that we're not 
storing anymore) and is set to 1 if the 
addition did carry. This pseudocode is 
trivial in all the assembly languages I've 
ever seen, for example, in x86 assembly: 

add ebx.ecx 
adc esi.edx 

Assuming the given registers contain the 
right values, the adc (add with carry) will 
add in the step and any carry from the 
previous addition. I mplementing this 
code in C -H-would be a mess. 

That's it for the U coordinate, but 
we conveniently ignored the V coordinate 
because it's a good deal trickier. L ike U , 
the V coordinate is linear for our span, so 
we can precalculate our increment and 
leave the integer part ofV out of our loop. 
H owever, as you can see from Listing 1, 
the integer part of the V coordinate is 
scaled to step vertically in our texture 
bitmap. This doesn't present a problem 
for the normal V step, but when the frac- 



tional part of V carries into the integer 
part, the source pointer no longer steps by 
1, it steps by the width of the texture 
bitmap. N ot even assembly language has 
an instruction to add in an arbitrary num- 
ber— like the TextureDeltaScan in Listing 
1— on carry. 

Q uickly adding in the vertical source 
step on V 's carry is where 99% of the pro- 
gramming brainpower is spent on linear 
texture mapping optimizations. I've seen 
about five or six ways of doing it myself, 
but by far the coolest, fastest, and most 
elegant way I've seen was invented by 
M ichael A brash. H owever, before I 
describe it, I 'm going to address the opti- 
mization a lot of the experienced texture 
mappers in the audience think I 'm going 
to use here. 

If you go out on the Internet and 
look for affine texture mappers, you'll 
undoubtedly run into a lot of very opti- 
mized x86 code that only works with 
power-of-two source texture sizes, and 
specifically two to the eighth power (or 
256-bytes wide for 8bpp textures), 
because if you keep your textures to a 
power-of-two width, you can very easily 
handle the V carry we're discussing using 
some special x86 instructions that operate 
on 8- bit portions of the full registers. 

Let's run through an example, where 
our source texture is 256 by 256. W e'll 
use the x86's ebx register, and its corre- 
sponding "byte registers," bh and bl. The 
byte registers are part of the 32 bit ebx 
register, and bl (b-low) is the lowest 8 
bits— bit through 7— and bh (b-high) is 
the next higher 8 bits— bit 8 through 15. 
I f we keep the U coordinate in bland the 
V coordinate in bh, we can use the follow- 
ing code to increment both U and V 
(assuming ecx and edx have the current 
UFrac and VFrac, respectively, and esi con- 
tains the texture pointer): 



add ecx , [DeltaUFrac] 

adc bl, [UlntStep] 

add edx , [DeltaVFrac] 

adc bh,[VIntStep] 

add esi, ebx 



N otice the second adc. It adds in the 
carry from the VFrac addition, but I just 
got finished saying how this wouldn't 
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Listing 2. The x86 Asm Inner Loop 



add edx,[DeltaVFrac] ; add in dVFrac 

sbb ebp.ebp ; store carry 

mov [edi],al ; write pixel n 

mov al, [esi] ; fetch pixel n+1 

add ecx,ebx ; add in dUFrac 

adc esi,[4*ebp + UVStepVCarry] ; add in steps 



work because V's carry needs to add in the 
width of the texture. The tricl< is that bh is 
actually already multiplied by the width of 
our texture— 256— by virtue of its bit 
position in ebx. Neat, huh? Now, given 
such a cool tricl<, why wouldn't we use it? 
There are two reasons: first, restricting 
yourself to power-of-two textures isn't 
very flexible and is bad for cache coheren- 
cy (see Behind the Screen, Oct./Nov. 
1995). M ore importantly, with the Pen- 
tium Pro, this code will run slowly due to 
a new pipeline stall called the Partial Reg- 
ister Stall (PRS).ThePRS happens when 
you modify one of the byte registers and 
then try to use the encompassing 32-bit 
register, much like the above code. The 
instruction add esi, ebx will stall for a very 
long time on the Pentium Pro. W hy did 
Intel let this happen? I have no clue, 
although th^ say it will let them increase 
the clock speed more than if they had pre- 
vented the stall. Regardless, it's there, and 
we'll need to live with it. 

So, given that we're not going to use 
the power-of-two texture trick, how do 
we write our code so it can carry an arbi- 
trary value into the pointer when VFrac 
overflows? Enter A brash's code snippet 
shown in L isting 2. T his is the code for a 
pixel from the middle of an unrolled loop, 
so there's a bit of setup not shown here, 
but imagine this same snippet concate- 
nated with itself a bunch of times. See if 
you can figure out how it works and then 
read on for the description of this tour de 
force of optimization. 

Hit the Pipe 

T here are so many cool things about this 
code it's hard to know where to start 
describing it, but, since we were dis- 
cussing the V carry, we'll start with how 
the code addresses that problem. T he 



first half of the solution is these two 
instructions: 

add edx , [DeltaVFrac] 

sbb ebp.ebp 

The first instruction adds in the 
fractional step as usual, but the second 
instruction saves the carry flag, using a 
neat trick involving the sbb (subtract 
with borrow) instruction. The sbb 
instruction is like the opposite of adc, it 
subtracts its source from its destination, 
but also subtracts the carry bit, so sbb 
ebp.ebp will subtract the ebp register from 
itself, giving if there was no carry, or-1 
if there was a carry. Thus, the carry bit 
from the VFrac addition is stored as a 
or a -1 in ebp. 

The second half of the solution 
comes with these instructions: 

add ecx.ebx 

adc esi,[4*ebp + UVStepVCarrj] 

T he first instruction is the UFrac 
addition, so after it completes, the carry 
bit is set appropriately. T he next instruc- 
tion is where all the action occurs. It's an 
adc, so it adds in the carry from the UFrac 
addition as you'd expect. H owever, it's 
an adc from memory, and it uses a two 
duord array to accomplish its magic. 
uvstepVCarry is the address of the second 
duord in the array, and the or -1 in ebp 
from the VFrac carry will select either the 
second duord if there was no V carry, or 
the first duord if there was a V carry 
(since 4 '-1 will subtact4 bytes from the 
array address). The only thing left is to 
make sure the array has the appropriate 
steps in it, including the U and V integer 
steps and the V carry step for the first 
element in the array. 



A s if the basic operation wasn't good 
enough, the pipelining on this code is 
amazing as well. The order of instructions 
perfectly fills both pipes on the Pentium 
and manages to run the two additions 
from memory— both two-cycle instruc- 
tions—in the Pentium U and V pipes at 
the same time (remember, the next pixel's 
code will come right after this pixel, so 
the add edx and the adc esi will run at the 
same time). The instructions are also far 
enough away from each other that there 
are no Address Generation Interlocks. 
Overall, it's a beautiful piece of code. 

Walidng and Chewing Gum 

Regardless of how amazing our integer 
affine inner loop is, we'll still be slower 
than we need to beif we're waiting for the 
floating-point unit to calculate the per- 
spective-corrected texture coordinates 
before starting each span. This is where 
the floating-point overlap I hinted about 
in the last issue enters in. M ost modern 
processors can execute floating-point 
instructions at the same time as integer 
instructions, and some, like the Pentium, 
can execute multiple floating-point 
instructions at the same time. As an 
example of integer and floating-point 
overlap, the following code will take 36 
cycles on a Pentium in double precision 
mode: 

fdiv [Numberl] 
fst [Nuinber2] 

The division takes 33 cycles, the 
store takes two cycles, and there's a one- 
cycle stall for trying to store the result of 
the division right after it's completed. 
G uesshow long thefollowing code takes: 

fdi» [Numberl] 
rept 33 

add ebx,ecx 
add edx,eax 

endm 

fst [Nuinber2] 

To guess correctly, you need to 
know that the rept macro repeats the 
contained code 33 times, so there are 
actually 66 instructions between the fdiv 
and the fst. T his is actually a trick ques- 
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tion because this code takes the same 36 
cycles as the first snippet, but we got to 
execute 66 integer instructionsforfree! 

W ell, we don't really get just any 66 
instructions for free, but we do get 33 U 
and V pipe slots in which we can try to 
get some worl< done before using the 
result of the division. Some instructions, 
lil<e integer multiplies, won't overlap with 
the floating-point unit, and you can't 
really do many other floating-point 
instructions at the same time as floating- 
point division, but we can start up the 



Listing 3. Naive Adding 



fid 


[al] 


1 


fadd 


[bl] 


3 


fstp 


[al] 


2+1 


fid 


[d] 


1 


fadd 


[dl] 


3 


fstp 


[d] 


2+1 


fid 


[el] 


1 


fadd 


[fl] 


3 


fstp 


[el] 


2+1 



perspective divide for our next span and 
have it calculate as we're processing the 
current span, making it almost free. 

Short Stack 

The second floating-point technique I 
mentioned, executing multiple floating- 
point operations simultaneously, is slight- 
ly more convoluted. The Intel floating- 
point architecture is stack based, which 
means almost all the floating-point 
instructions will only operate on the top 
of the stack. This made it hard for Intel 
to pipeline the floating-point unit for the 
Pentium since all the instructions were 
vying for the same register— the floating- 
point top-of-stack register. So, instead of 
breaking all the existing floating-point 
code by making a bunch of new instruc- 
tions to randomly access the floating- 
point registers, Intel decided to make it 
possible to move operands around on the 
stack very quickly. I actually wish they'd 
broken the code and made random regis- 



ter access easy, but Intel doesn't usually 
ask my opinion on these things, so I'll 
quickly describe the stack- based solution. 

L isting 3 shows the obvious way to 
add some numbers together, along with 
the cycle counts for each instruction. It's 
implementing this C -H- code: 

al += bl; cl += dl; el += fl; 

T he code executes in 21 cycles, 
including the three stalls (the 2-f-l fstp 



Listing 4. Quicl^ Adding 



fid [al] ; 1 

fadd [bl] ; 1 

fid [cl] ; 1 

fadd [dl] ; 1 

fid [el] ; 1 

fadd [fl] ; 1 

fxch st(2) ; 

fstp [al] ; 2 

fstp [cl] ; 2 

fstp [el] ; 2 
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timings) for storing the results of an 
operation immediately following its 
completion. L isting 4 shows an alternate 
implementation of the same code, which 
executes in 12 cycles, or almost twice as 
fast. T he instructions can pipeline if you 
don't access their results before the 
instruction is finished (the fid instruc- 
tion pushes its operand onto the stacl<, 
and the previous fadd continues on its 
operand even as it's moved down one 
stacl< position). I n our example, the fadds 
tal<e 3 cycles each in L isting 3, but only a 
single cycle each in Listing 4. 

The second thing to notice is that 
the fxch instruction is free in L isting 4. 
T his is I ntel's offering to the angry G od 
of Processor Architecture, who threat- 
ened to smite Intel dead if it didn't 
pipeline the floating-point unit. The 
almost-free fxch instruction malces it 
possible— not easy, just possible— to 
pipeline your floating-point code even 
though most of the instructions only 
operate on the top- of- stack register. 
Using fxch, you can move things around 
while they're still calculating, lil<e the 
el+fl addition in Listing 4. I called it 
"almost-free" because there are some 
restrictions you have to obey to l<eep it 
free; for example, the following instruc- 
tion must be a floating-point operation, 
as it will stall a cycle if the following 
instruction is an integer operation. Intel's 
AP500 Application Note, available on 
their www.intel.com site and the Intel 
A rchitecture L abs C D , describes this 
technique in detail. 

Finally 

There are more tricl<s in the assembly 
texture mapper that deserve a mention, 
but they're all minor and I'm out of 
space. You can find them in the code 
itself. As with most assembly code, the 
texture mapper is way too long to 
include here in the magazine. You can, 
however, get it in the texture mapping 
archive on the G ame D e/ eloper web site, 
on its ftp site (ftp.mfi.com/pub/ 
gamedev/src), or on my homepage at 
http://ourworld.compuserve.com/ 
homepages/checl<er. 

H ow fast is it? W ell, I must admit, 
I'm not finished optimizing it yet as I 



write this (again, see the comment about 
estimating how long it tal<es me to do 
something at the beginning of this arti- 
cle), but it's already two times as fast as 
the C -H- subdividing affine texture map- 
per, and I hope to make it another two 
times faster by the time you read this 
and are able to pick up the code. I t's cur- 
rently drawing 4.5 million pixels per sec- 
ond on a Pentium 133, which is 5 times 
faster than our original texture mapper, 
and fast enough to do 70 frames per sec- 



ond at 320 by 200 if you're not doing 
anything else except texture mapping. 
That's definitely fast enough for a high- 
end 3D game, and I think we can safely 
say we've met the goals we set for our- 
selves at the beginning of this series, 
even if we did meet them a bit late. ■ 

You can e-mail Chris H 6d<er at died<- 
er@bix.coin. D on't be surprised if it takes 
him a whileto respond, although he'll assure 
you it will onlytakea seoxid.... 
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Data Capture 
of 3D Models 




A wireframe model of Armadon, one of the beasties in tlie Primal Rage game. Every character 
in the game started out as a sculpture, which was then digitized. A coordinate mapping sys- 
tem ensured realistic movement. 



Afficionados of the popular 
arcade video game, Primal 
Rage, are well acquainted 
with the combatants— 
Sauron, Talon, Blizzard, Ver- 
tigo, D iablo, C haos, and 
Armadon. These seven pre- 
historic fantasy creatures are 
some of the largest fighting game char- 
acters, and each has a distinct personali- 
ty and fighting style. 

W hen T ime W arner I nteractive I nc. 
in M ilpitas, Calif, decided to recreate Pri- 
mal Rage for play on home video game 
equipment, it was imperative that nothing 



about the well-known characters changed 
as they made the transition to new hard- 
ware. M aintaining consistency across 
platforms was a challenge, however, 
because graphic imaging requirements for 
each game device differ. For example, the 
resolution available in a CD-ROM ver- 
sion, with its prerendered images, is far 
superior to that of the arcade game which 
renders scenes in real-time. Consequent- 
ly, CD-ROM creatures can display more 
detail and move more realistically. 

To ensure that Sauron, Talon, and 
company made an accurate transition to 
the new PC CD-ROM version of the 
game. Time W arner hired 3N ameSD , a 
Santa M onica, Calif.- based geometric 
modeling company. 3Name3D sculpted 
each of the Primal Rage creatures, then 
digitized the sculptures using the Faro 
Arm, a portable coordinate measuring 
machine from F aro T echnol ogles in 
LakeM ary, Fla. 

According to 3N ameSD CEO, 
Sandeep D ivekar, this approach assured 
his company of getting truly realistic 
recreations of the creatures. "0 bjects that 
must be replicated exactly must be digi- 
tized or scanned rather than modeled on 
screen using CAD or other modeling 
software," says D ivekar. "W e chose a 
coordinate measuring machine to control 
where we captured the x, y, z coordi- 
nates. W e chose the Faro A rm because 
the Primal Rage sculptures we created 
were up to three-feet long, and we need- 
ed its large working envelope." 

Three Architects 

3N ameBD was founded by three archi- 
tects— Oscar Yglesias, Steve Wallock, 
and D ivekar. T he company creates digi- 
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tal models for clients in a variety of 
industries and offers a collection of 
ready-made computer models. 

For the Primal Rage project, Time 
Warner supplied 3Name3D with the 
original nine-inch latex models that had 
formed the basis for the arcade game 
characters. To create the arcade game, 
these fully jointed models had been 
filmed using the stop- motion technique, 
in which a series of painstal<ingly small 
movements are recorded. Stop- motion 
would not work for the PC CD-ROM 
game, according to Divel<ar, because it 
would not supply the sufficient level of 
detail or the highly realistic motion 
Time W arner wanted. 

3N ameBD 's first step was to create 
its own set of sculptures of the Primal 
Rage creatures. They made them bigger 
to capture more detail but otherwise they 
were identical to the original latex mod- 
els. With the exception of Blizzard (a 
gorilla), the new sculptures were con- 
structed of the modeling clay, Sculpey. 
Sculpey couldn't support Blizzard's long 
arms, however, so Blizzard was sculpted 
in clay. A latex mold was made of the 
clay, then Blizzard was cast in plaster of 
pariswith armatures supporting hisarms. 

Once the sculptures were complete 
and approved by T ime W arner, the 
process of recreating them as digital 
models began. First, grid lines were 
placed on the sculptures to indicate the 
locations of the points (x, y, and z coor- 
dinates) to be entered into the computer. 
Coordinate location was a critical issue 
because the models were going to be ani- 
mated. "This meant they had to be bro- 
ken at joints, with each joint positioned 
precisely so the movement would look 



realistic," explains Divekar. (Imagine a 
knee positioned mid-way up the thigh. 
The motion of that leg would not look 
very realistic.) 

Because grid line placement affect- 
ed the location of the joints and 
3N ameBD needed precise control over 
these lines, laser scanning was ruled out 
as a method of capturing the coordi- 
nates. "If a model is going to sit off in 
the corner of a digital set and not move, 
it doesn't need joints and, in that situa- 
tion, laser scanning is fine," says 
Divekar. "But laser scanners pick up 
point locations in a regular pattern. A 
jointed, moving model requires irregular 
grid lines. W ith a coordinate measuring 
machine, grid lines can be placed in 
response to the animator's needs. The 
user tells it where to capture coordinates 
by pointing at them and then clicking 
the probe." 

Although on previous projects 
3N ameBD had used another company's 
small BD digitizer, its probe was limited 
to a sphere of 12 inches. The Primal 
Rage models were three-feet long. To 
get the reach they needed, BN ameBD 
bought a portable coordinate measuring 
machine with a six degrees of freedom 
arm and a spherical working envelope of 
eight feet. 

Called a "liberated" coordinate 
measuring machine, the Faro Arm used 
by BN ameBD is not restricted to three 
axes. Unlike some other digitizing meth- 
ods, there are no line-of-sight limita- 
tions or restrictions on digitizing metal 
objects. Although generally used in labs, 
engineering offices, and manufacturing 
facilities, computer artists are now start- 
ing to use it. The Faro Arm features 



Caren D. Potter 

How did^meWferner 
move critters to a 
new platform? A 
portable coordinate 
measuring machine 
was key to replicating 
the arcade game 
characters for a PC 
CD ROM version of 
Primal Rage, 
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Before and after pictures of Vertigo (ieft) 
on top and tlie rendered versions are beiow. 



direct serial port input into AutoCAD 
and ottier modeling pacicages and sup- 
ports standard output formats sucti as 
IGES, ASCII, DXF, and ACL. 

One-Person Digitizing 

Often, digitizing large objects is a two- 
person job— one person operates the 
probe while the other watches the com- 
puter screen to make sure data is cap- 
tured correctly. H owever, 3N ameBD 
needed only one person to digitize the 
Primal Rage creatures because the soft- 
ware they used to capture input from the 
arm, M ira I maging's H yperSpace, incor- 
porated audio feedbacl<. 

Explains D ivel<ar, "H yperSpace, 
which we run on a M acintosh computer. 




(right). The wireframe images appear 



uses audio cues to provide feedbacl< to 
the operator. W hen a point is entered, it 
signals the computer to emit one l<ind of 
sound. If the point has to be locked on 
to a previous point, the computer makes 
a different sound when the two points 
are identified. The person who did the 
digitizing of Primal Rage sculptures, 
who was also the artist who had created 
them, spent very little time looking at 
the screen." 

H yperSpace was also the software 
used to create the surfaces over the 
points. After the points representing a 
certain area of the sculpture were 
entered, the software was given the com- 
mand to place a skin over them. 

W hen the model was completely 
digitized and surfaced, the H yperSpace 
file was transferred to W avefront's 
Advanced Visualizer software running 
on a Silicon G raphics workstation. 
There, it was cleaned up and broken 
down into logical groups to make joints. 
The last step was translating the 
Advanced Visualizer file to 3D Studio 
file format. (3D Studio was the model- 
ing and animation software used by 
T ime W arner.) 

It took 3Name3D about four days 
per creature to complete the process of 



digitizing a sculpture and adding sur- 
faces to the computer model. T he entire 
operation, from making a sculpture to 
creating a fully surfaced, jointed digital 
model, took about 10 days per creature, 
and 3N ame3D modeled five of the seven 
Primal Rage creatures. 

For 3Name3D, the Primal Rage 
project has led to additional work, in 
part due to the use of a digitizing arm. 
"T here's no way we could have done this 
without one," says D ivekar. G ame artists 
interested in rapidly creating complex 
shapes would do well to consider the 
advantages of sculpting and digitizing 
models rather than creating them entire- 
ly digitally. The availability of large 
envelope, six-degree-of-freedom digitiz- 
ing arms makes this a valuable cost-cut- 
ting option. 

The PC CD-ROM version of Pri- 
mal Rage was released on August 25, 
1995 along with versions for other 
home game equipment such as the Sega 
Genesis, Super Nintendo Entertain- 
ment System, and N intendo G ame 
Boy. T ime W arner has already shipped 
more than one million units of these 
new releases, and appears to have 
another hit on its hands. ■ 



Caren D . Potter is a freelance writer 
living in M cKinleyville, Calif. She has 
been writing about ODmputer technology, in 
its various forms, for 10 years Contad: her 
via e-mail at cpotter@northcoast.CDm. 



A final screenshot of Talon vs. 
Blizzard. 
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Figure 1. The result of Z buffering polygon A and B is shown in Box C. 



Years ago— when I got my feet 
wet in the virtual world of 3D 
computer graphics— I stum- 
bled upon an algorithm. This 
algorithm, in case the title of 
this article hasn't completely 
spoiled the surprise, is popu- 
larly known as the Z buffer 
algorithm and deals with the slippery 
problem of visual surface determination. 
Visual surface determination and its con- 
verse, hidden surface elimination, are 
two approaches to solving the age-old 
problem of correctly rendering 3D sur- 
faces on a 2D screen. 

I n the real world, mere mortals can- 
not see through opaque surfaces. H ow- 
ever, in the world of 3D computer 
graphics, no such limitation exists. In 
fact, we 3D programmers go to great 
lengths to impose this limitation on our 
3D worlds so as to model the real world 
more accurately. The only other alterna- 
tive to imposing this limitation on our 
3D worlds is drawing all polygons in the 
dataset in an arbitrary order, ignoring 
their 3D properties, which will almost 
guarantee that some distant surfaces will 



show through closer surfaces, producing 
a surrealistic effect that is generally not 
desirable. 

One method of dealing with this 
annoying problem of distant objects 
showing through closer ones is to draw 
all surfaces (polygons) in a bacl<-to-front 
order. If done properly, this assures us 
that the resulting view will be rendered 
accurately. Known as the Painter's or 
Depth Sort Algorithm, this approach 
has three serious flaws: first, the amount 
of time it takes to sort the surfaces 
increases exponentially with regard to 
the number of polygons in the dataset; 
second, precious time is wasted rasteriz- 
ing pixels that will be over-written fur- 
ther down the list; finally, surfaces can- 
not penetrate each other (such as a boat 
in water, or aircrafts soaring through 
clouds). Though you can probably over- 
look the second and third deficiencies, 
the first one is tough to swallow. In large 
datasets, the amount of sorting and test- 
ing that must be performed is prohibi- 
tively complex— rendering this method 
useless for many modern applications. 
Thus, many developers of 3D software 
have turned to two more flexible and 
faster approaches: BSP (Binary Space 
Partition) trees and Z buffering. 

A BSP tree is a collection of poly- 
gons listed in an order based on the rela- 
tive position and orientation of all poly- 
gons to each other. Typically, the cre- 
ation of this BSP tree is rather time- 
consuming, and, therefore, a BSP tree 
compiler creates it in advance. Though 
this method provides extremely quick 
sorting, it suffers from other problems of 
the Painter's A Igorithm and imposes a 
limitation of its own— it restricts the 
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dataset to static objects. The static 
requirement of the BSP tree has 
prompted a number of developers to 
search for ways to integrate moving 
objects into a BSP tree without per- 
forming time-consuming calculations, 
most of which are less than successful. 

W ith the rise of faster processors, 
more memory, and video cards with 
onboard Z buffers, the Z buffer algo- 
rithm is starting to lool< attractive to 
many developers simply because it over- 
comes all flaws of the Painter's Algo- 
rithm (save number two, where a num- 
ber of adaptations may be used while 
maintaining visual accuracy). The Z 
buffer algorithm is an image-precision 
algorithm, meaning it deals with visual 
surface determination at the image 
level, requiring an increase in memory 
for an increase in resolution. With 
8M B of memory standard on today's 
machines and 16M B common, this 
memory requirement is somewhat less 
than restricting, especially considering 
the number of problems the Z buffer 
eliminates. 

The Z buffer is, as implied by its 
name, a linear array of Z (the depth 
coordinate) values. Each pixel in the 
viewport corresponds to an element in 
the Z buffer. This array is designed to 
hold the Z values of all the visible poly- 
gons in the viewport. W hen rasterizing 
a polygon, before each pixel is written to 
the viewport, the corresponding Z value 
in the Z buffer is checl<ed against the Z 
value of the pixel being rasterized. If the 
Z value of the current pixel is closer to 
the viewpoint than the Z value previous- 
ly stored in the Z buffer, the current Z 
value is stored in the Z buffer and the 



pixel rasterized; if not, the process con- 
tinues. (See Figure 1 for illustrations.) 
As you might have guessed, this means 
theZ buffer must be cleared (reset) every 
frame to some number (the farthest pos- 
sible Z value), though a later optimiza- 
tion removes this requirement. 

The only apparent difficulty we 
might have is determining theZ (depth) 
at each point, which is not as hard as it 
sounds. The equation for a plane or 
polygon is as follows: 

Ax-hBy-hCz +D =0 

Solving for Z gives us: 

Z =(-Ax- By- D )/C 

H owever, we can compute Z incre- 
mentally for coplanar surfaces, which is 
fortunate for our sal<es because it saves 
us from solving the above at each pixel. 
nee the value of Z has been deter- 
mined (which we'll call Zc), the value of 
Z at the following pixel is: 

Zc-(A/C) 

A single subtraction per pixel! As 
fate would have it, however, we'll mostly 
be interpolating values instead of 
direct Z values. T he reason is simple: Vz 
is linear in screen space, and can be 
interpolated using a linear equation, 
whereas Z is linear in 3D space, and 
cannot be linearly interpolated in screen 
space. Since this means our Z values are 
inverted, we must clear the Z buffer to 
zero each frame, which represents a lit- 
eral infinity: the farthest possible Vz 
value. On the positive side, interpolating 



J ohn De Goes 

If you are involved 
with 3Dgrapliics, you 
are familiar with the 
problem of visual 
surface determina- 
tion, ^e Z buffer 
algorithm can help 
you get around the 
problem, 
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Listing 1. Classes to Mal<e a Z Buffer (Visual Surface Determination Algorithm Implementation) 



a#include <Nath.H> 
#include <liindows.H> 

// The precision to the right of the imaginary decimal point: 

const ZPREC = 26; // sOOOOO. 00000000000000000000000000 = 0.000000015 



class ZBuffer { 
protected: 

long *ZBuff , ZTrans; 

UQRO Init, Code; 

unsigned int Width, Height; 
public: 

enum { NoHem = 0, Success }; 



// Performs an "unsafe", fast Z buffer write: 

// (Dest must be a 256 color buffer equal in dimensions 

// to the Z buffer.) 

•old FastUrite ( unsigned int Index, long Z, BYTE Val, BYTE *Dest 



if { ZBuff [ Index ] < Z ) 
{ 

ZBuff [ Index ] = Z; 
Dest [ Index ] = Val; 
} 

} 



// Sets defaults: 

ZBuffer () : Init ( ), Code { NoHem ), 

ZBuff { NULL ), ZTrans ( ) { } 

// Accepts width and height for Z buffer creation: 
ZBuffer { int «, int H ) : Init ( ), Code ( NoHem ), 
ZBuff ( NULL ), ZTrans ( ) 
{ Create ( U, H ); } 

// Deallocates memory: 

'ZBuffer () { delete [] ZBuff; } 

// Initializes the Z buffer: 
inline BOOL Create ( int W, int H ); 

// Width and height member functions: 
unsigned int GetUidth () { return Uidth; } 
unsigned int GetHeight () { return Height; } 

// Returns the 1/Z translate »alue: 
long GetZTrans () { return ZTrans; } 

// Returns the error code: 

UQRD GetCode () { return Code; } 

// Returns a pointer to the Z buffer (use with caution): 
long *GetPtr () { return ZBuff; } 

// Performs a "safe", slow Z buffer write: 

// (Dest must be a 256 color buffer equal in dimensions 

// to the Z buffer.) 

void Write ( WORD X, UORD Y, long Z, BYTE Val, BYTE *Dest ) 
{ 

unsigned int Index; 

if ( ( Init ) M ( X < Kidth ) tt ( Y < Height ) ) 
{ 

Index = X + Y * Uidth; 
if ( ZBuff [ Index ] < Z ) 
{ 

ZBuff [ Index ] = Z; 
Dest [ Index ] = Val; 
} 

} 

} 

// Performs a "safe", slow Z buffer read: 
long Read ( UGRD X, WORD Y ) 
{ 

if ( { Init ) M ( X < Width ) M ( Y < Height ) ) 

return ZBuff [ X + Y * Width ]; 
return 0; 
} 



// Performs an "unsafe", fast Z buffer read: 
long FastRead ( unsigned int Index ) 
{ 

return ZBuff [ Index ]; 
} 

// Qears the Z buffer to zero: 

// (Optionally accepts the number of completed 

// frames to aid in the clear reduction algorithm.) 

BOOL Clear ( unsigned int FrameCount = ); 

}; 

inline BOOL ZBuffer: : Create ( int W, int H ) 
{ 

// Function creates a Z-buffer - can be called 

// in succession: 

delete [] ZBuff; 

ZBuff = NULL; 

Init = 0; 

ZTrans = 0; 

if ( ( ZBuff = new long [ U ♦ H ] ) == NULL ) 
{ 

Code = NoHem; 

Uidth = 0; Height = 0; 

return 0; 

} 

Init = 1; Code = Success; 
Width = U; Height = H; 

// Qear the Z buffer: 
return Qear (); 
} 

class ZEdge { 
protected: 

long Z, ZStep; 
public : 

ZEdge : Z ( ), ZStep ( ) { } 
// Clip function for clipping a coordinate to boundary: 
»oid Clip ( int C, const B ) 
{ 

// Takes advantage of the fact that 
//{(a*(b*c))/c)is equal to ( a * b ) : 
if { C < B ) 

Z += ZStep * ( B - C ); 

} 

// Init function for stepping along polygon edges: 
inline void Init ( float DneOverZl, float Dne0verZ2, 

int Length, ZBuffer JiZBuff ); 
// Init function for stepping along scanlines: 
inline void Init ( ZEdge JiLeft, ZEdge SRight, 
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Listing 1. (Continued from p. 40) 



Listing 2. Code for Z Buffer Classes 



unsigned int Width ); 

// Step operators: 

void operator ++ ( ) { Z += ZStep; } 

void operator ++ ( int ) { Z += ZStep; } 

// Function returns the current fixed-point Z value: 

long GetZ () { return Z; } 

}; 

inline void ZEdge::Init ( float OneDverZl, float OneDverZ2, 
int Length, ZBuffer JiZBuff ) 

{ 

// Calculate the steps for a polygon edge: 
long FixedZl, FixedZ2; 
if ( Length ) 
{ 

FixedZl = long ( OneOverZl * float ( 1 « ZPREC ) ) ; 
FixedZ2 = long ( 0ne0verZ2 * float ( 1 « ZPREC ) ) ; 
Z = FixedZl + ZBuff .GetZTrans (); 
ZStep = ( FixedZ2 - FixedZl ) / Length; 
} 

else { 

Z = 0; ZStep = 0; 
} 

} 

inline void ZEdge::Init ( ZEdge iiLeft, ZEdge &Right, 
unsigned int Uidth ) 

{ 

//Calculate the steps for a scan-line: 
if (Uidth) 
{ 

Z = Left. GetZ (); 
ZStep={Right.GetZ - Z) / Width 
} 

else { 

Z=0; ZStep = 
} 

} 



#include "ZBuffer. HPP" 

BOOL ZBuffer: : Clear ( unsigned int FrameCount ) 
{ 

// Function clears — if necessary — the Z-buffer to 
// zero (infinity): 

// Calculate the number of frames before each Z buffer 
// clear: 

unsigned int MaxWait = pow ( 2. OF, ( 31. OF - ZPREC ) ); 
unsigned int N, Length, Rem; 

// Determine if a clear is in order: 
if ( HaxWait == ) 
Rem = 0; 

else Rem = FrameCount 7, MaxWait; 

Length = Width ♦ Height; 
if ( Init ) 
{ 

if ( Rem == ) 
{ 

// If clear reduction is enabled, there is no need 
// for an assembly Z buffer clear function as the 
// Z buffer is cleared only once per so many frames, 
for ( N = 0; N < Length; N++ ) 

ZBuff [ N ] = 0; 
ZTrans = 0; 
} 

// Else no clear - adjust translate value: 
else ZTrans += ( 1 « ZPREC ); 

// Return success: 
return TRUE; 
} 

// Return failure: 
return FALSE; 



Vz allows US to use fast linear equations, 
while at the same time providing infor- 
mation necessary for perspective texture 
mapping. 

Optimizations are also important. 
Two of the most blindingly obvious per- 
formance reducers of the Z buffer are 
the test per pixel and the actual clearing 
of the Z buffer. The clearing of the Z 
buffer cannot be avoided, but you can 
reduce the number of Z buffer clears you 
must perform by using 32-bit integers 
for the Z buffer. I call this optimization 
the clear reduction algorithm, and it has 
saved many a processor cycle on my own 
applications. Since the values in the Z 
buffer are never greater than 1, and 
because 1 is the closest possible value to 
the viewport, it is possible to fool the Z 
buffer into thinking that each frame is 



closer than the previous frame by adding 
a translation value to the Vz terms, thus 
eliminating the need to clear the Z 
buffer every frame. You can thinl< of it as 
a translation of all polygons, bringing 
them closer to the viewport each frame 
by an amount proportional to the maxi- 
mum extents of the dataset. T hough this 
may sound a bit difficult, it adds but a 
few lines of code. 

To implement this optimization, 
for every new frame you should add 1 
more to each of the Vz terms than you 
added the previous frame, tal<ing care 
not to exceed the limit of the data- type 
you are dealing with. By definition, the 
Vz terms will never exceed a [0-1] 
range, meaning that adding an offset to 
these terms will effectively translate the 
dataset closer to the viewpoint by an 



amount equal to the translate value. 
The number of frames you can wait 
before you clear the Z buffer (and reset 
the translate value) will depend on 
whether or not you're using fixed- point 
or floating-point math. If you use fixed- 
point math, the number of frames will 
depend on where you place your imagi- 
nary decimal point. Traditionally, you'll 
have a ClearZBuffer function in your 
main loop, perhaps such as: 

aearZBuffer ( ZBuffer ); 

Using this optimization, that same 
portion of code might become: 

if ( ( FrameCount '/. MAX_MAn ) == ) 

{ 

aearZBuffer ( ZBuffer ); 
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ZTrans = O.OF; 
} 

else ZTrans += l.OF; 

Obviously, this example uses float- 
ing-point math, which is a definite no- 
no as far as fast 3D graphics are con- 
cerned. T he ZTrans term is the value that 
is added to the Vz starting terms at each 
of the polygon's vertices preceding ras- 
terization. MAX.WAIT, is of course, the 
maximum amount of frames before the 
Z buffer is cleared, and FrameCount is the 
total number of frames that have been 
completed. 

If much of what has been discussed 
regarding Z buffers has been review for 
you— with the exception of the clear 
reduction algorithm— you're probably 
wondering what you can do to eliminate 
the test per pixel that is required for an 
academic Z buffer. T he solution is theo- 
retically simple, but a pain to implement: 
Z buffer at the scan-line level instead of 
the pixel level. Using this approach, you 
never have to write a pixel more than 
once, and the Z buffer never has to be 
cleared. N otethat, in such an implemen- 
tation, the Z buffer becomes a linl<ed list 
of scan-line information. 

I t's beyond the scope of this article 
to discuss the subject of proper rasteri- 
zation, so I will provide a set of 32-bit, 
operating system independent classes 
instead of a full rasterizer. The classes 
can easily be added to just about any 
rasterizer. The classes, whose declara- 
tion appears in Listing 1 and whose 
non-inline code appears in Listing 2, 
implement a Z buffer algorithm in 
fixed- point mathematics and include all 
the necessary code for the clear reduc- 
tion algorithm (see above). Of particu- 
lar interest is the ZBuffer class's Clear () 
member function. This function 
optionally accepts the number of frames 
that have been displayed since the pro- 
gram's initialization. 

If you do not wish to use the clear 
reduction algorithm, it is not necessary 
to provide this argument; however, 
providing it lets the function reduce 
the number of Z buffer clears that 
occur without sacrificing visual quality. 
In the ZEdge class, you will notice that 



one of the initialization functions 
accepts two values. You can calcu- 
late these values by tal<ing the inverse 
of the Z values at the vertices of the 
polygon. The other initialization func- 
tion accepts two ZEdge classes, which 
represent the sides of the polygon at a 
given scan line. 

Typically, you will use one ZBuffer 
object per window, and three ZEdge 




objects for rasterizing polygons. One 
ZEdge object will represent the right side 
of the polygon being rasterized, anoth- 
er, the left side, and the third, the scan 
line being rasterized. If you perform 
polygon clipping at the image level, you 
will find the Clip () member function 
most helpful, which accepts a coordi- 
nate and the boundary for that coordi- 
nate. (T he coordinate will be an X or Y 
point, depending on which axis you are 
clipping on; an X point for scan-line 
clipping, and a Y point for the top of 
the polygon clipping.) The ZEdge class 
overloads the ++ operator, so each time 
you step in a coordinate (that is, step- 
ping down the left or right edge of the 
polygon or across the scan line), you can 
simply use this operator. 



For those curious souls among you, 
I decided to put multiple Z buffer read 
and write functions in the ZBuffer class 
because while debugging an application, 
you can use the slow, safe functions; 
when optimizing, you should be able to 
easily convert to the fast, unsafe func- 
tions. Your application can use all the 
help it can get during debugging, and 
since the safe functions cannot do any- 
thing harmful to your system memory 
(barring unequally sized Z buffers and 
screen buffers), you can be assured that 
the application's problems will not be 
related to theZ buffer classes. 

One last word on the provided 
source code: the Z buffer write func- 
tions will actually write to the video 
buffer, but the buffer must be equal in 
dimensions to that of the Z buffer, and 
each byte in the buffer must represent a 
single pixel (with a range of 256 colors). 
I n mode 13h, for instance, this is the 
case, as it is for many windowed appli- 
cations running under Windows 95 or 
Windows NT. 

For a discussion on proper rasteriza- 
tion, I suggest checking out the highly 
regarded Computer Graphics: Principles and 
Practice (Addison-W esley, 1990) by 
Foley, van Dam, Feiner, and H ughes, or 
back-ordering C hris H ecker's excellent 
series of Game D eveloper articles on tex- 
ture mapping, which also covers correct 
rasterization. For more information on 
the clear reduction algorithm, along with 
general information and source code for 
Z buffering, perspective texture mapping, 
Phong shading, intensity interpolation, 
Gouraud shading, and related informa- 
tion, you can pick up my up-coming 
book. Cutting Edge 3D Game Program- 
ming (Coriolis G roup, 1996). There are 
many resources out there for anyone 
interested in thetopic. ■ 



John D e Goes is a freelance C/C -l-l- 
programmer currently working on high- 
performance 2- D and 3-D graphics soft- 
ware for individuals and companies 
wealthy enough to afford his outrageously 
high rates. He can be reached at 
75404. 2752@compuservecom for a mere 
$10 a message(plustax). 
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Full-Screen Graphics 
for Macin-tosh 
and Windows 95 



best entertainment meticu- 
lously crafts an experience for its 
audience. J ust as the best film 
directors carefully control the 
viewer's experience, the best game 
designers carefully control the 
player's experience. In simulation 
and strategy games, this often 
involves a system of overlapping windows 
the player can arrange to access maps, 
charts, and tools they need to play effec- 
tively. M ost adventure and action games 
immerse the player in the game world by 
controlling every visible pixel. In such 
games, window elements like caption bars, 
window borders, and other applications in 
the bacl<ground waste space and intrude 
on the experience. 

G ames that use windows can benefit 
from a cross- platform windowing library 
lil<e the one we've seen so far in XSplat. 
For games that want the whole screen, 
however, XSplat as it stands solves the 
wrong cross- platform problem. 

T his month, I 'm going to step bacl< a 
bit from the XSplat windowing system 
and head off in a different direction. 
W e're going to look into enabling full- 
screen graphics on W indows and M acin- 
tosh, leaving their integration with XSplat 
for another day. 

Once again, I'm going to describe a 
bit too much code to print in a magazine 
article, so you'll find the complete source 
code on theGameD a/ eloper ftp site. 

Direct to Windows 

The amount of hype and number of new 
trademarks surrounding the W indows 95 
Game SDK Featuring DirectX has been 
incredible. The praise is also deserved: the 
D irectX team at the 'soft bent over back- 



wards to provide W indows 95 applications 
low- level hardware access comparable to 
what has traditionally been available only 
under DOS. M icrosoft even provides a 
consistent interface to eliminate the night- 
mare configuration programs, buggy 
VESA drivers, and technical support calls 
over IRO and DM A settings Or such is 
the religion it preaches. 

W e'll start our D irectX experimenta- 
tion with a function that sets up a com- 
plete full-screen, double-buffered environ- 
ment for us, called BeginFuUScreen. You 
tell this function the display settings you 
want, and it sets everything up for you. 
L isting 1 shows the complete source code 
for BeginFuUScreen, if you want to follow 
our negotiations with D irectD raw. 

W e need a window. A ny window 
will do because it's just an anchor for 
D irectD raw, so we'll just use a static text 
window. The fun begins when we hook 
up with DirectDraw. DirectDrawCreate 
returns a pointer to a D irectD raw CO M 
object, essentially a pointer to a table of 
DirectDraw functions You can think of it 
as a C -H- object except that when you're 
done with it, you call Release instead of 
using the delete operator. 

nee connected to D irectD raw, Set- 
CooperatiueLevel tells the system that we 
want to take over the video hardware for a 
while, and SetDisplayMode makes the actual 
resolution switch. If the requested mode 
isn't available, SetDisplayMode will return 
an error code (something other than 
OD.OK), and we'll bail out of the setup func- 
tion. W e're going to run our sample appli- 
cation at 640- by- 480- by- 8, a mode avail- 
able on 99.99% of PC video hardware and 
a required mode in all M acintosh monitors 
other than the full- page portrait display. 
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After switching the video mode, the 
static text window we created fills the 
screen. D irectD raw only uses the window 
as a linl< to the operating system, handling 
all the graphics through DirectDraw sur- 
faces. The window could be 1-by-l and 
we would still have full-screen graphics, 
though we'd have problems receiving 
mouse messages occurring over most of 
the screen. 

DirectDraw uses low- level surfaces, 
not high-level windows, so we need to 
create a primary surface representing the 
visible portion of video memory, the 
whole display. T o create a surface, you use 
CreateSurface, passing a DDSURFACEDESC 
structure describing the surface you want. 
The primary surface can have secondary 
(off- screen) surfaces attached to it to 
enable hardware page-flipping, so we'll try 
to tal<e advantage of that. 

We begin by setting duBackBuffer- 
Count to 2 and including the DDSCAPS.FLIP, 
DDSCAPS.CDMPLEX, and DDSCAPS.VIDEOHEMORY 
flags in our primary surface request. This 
request asks DirectDraw to create a pri- 
mary surface and to allocate two addition- 
al buffers in off-screen video memory that 
we can page flip into visible memory. If 
this fails, we try again for a primary sur- 
face with only one off-screen buffer in 
video memory, and if this fails, we just 
accept a standard no-frills primary surface. 

You may be wondering why we go 
for two offscreen buffers if we want only a 
double-buffered library. Well, Direct- 
Draw's page flipping function can take 
place asynchronously, temporarily pre- 
venting access to the two surfaces being 
switched. It may wait for a vertical retrace 
before flipping or biting, which means 
that an attempt to lock the offscreen sur- 



face immediately after a call to Flip or Bit 
may fail, forcing you to burn cycles wait- 
ing for the video hardware to catch up. 
T he flip or bit doesn't involve the third 
buffer, though, so one surface will always 
be available for drawing. If you can triple 
buffer, your application will never have to 
wait on a lock. 

W ith a primary surface in hand, we 
now need to go for a secondary surface. If 
DirectDraw succeeded in creating a page 
flipping surface, GetAttachedSurface will 
return a pointer to the off- screen buffer. I f 
we had to settle for a simple primary sur- 
face, we have to create a second surface 
manually. The PageFlip global will tell us 
later what type of surface we have. 

Finally, we have to set up a color 
environment by setting up an array of 
PALETTENTRY Structures, passing it to Cre- 
atePalette, and passing the resulting 
DirectDrawPalette pointer on to 
SetPalette. 

If all this succeeds, we'll have the 
full-screen graphics environment we 
always wanted (and always had under 
DOS!). 

Managing the 
Macintosh Display 

Until recently, Macintosh systems 
required a specific dot pitch in their 
monitors. You could change the bit 
depth of the display, but if you wanted 
more pixels, you bought a larger moni- 
tor. W ith the introduction of the Pow- 
erM acs, Apple made a number of 
changes to their software architecture, 
including the Display M anager, which 
worked its way back to the 68K M acs in 
system 7.5.1. W ith the D isplay M anag- 
er installed, it's possible for M ac appli- 



mtfyj / www.mfi.conrV gdmag 



J on Blossom 

DrectD'aw and 
cross- platform 
compatibility? Is it 
possible? Not only 
is it possible, 
we've got the code 
to prove that it's 
possible! 
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Listing 1. Setting Up a Full- Screen Environment Using DirectDraw (Continued on p. 47) 



static HUND Window; 
static HINSTANCE ghlnstance; 

static LPDIRECTDRAU pDirectDraw; 
static LPDIRECTDRAUSURFACE pPrimarySurface; 
static LPDIRECTDRAUSURFACE pOffscreenSurface; 
static LPDIRECTDRAUPALEHE pPalette; 

static int PageFlip; 

int BeginFullScreen(int Width, int Height, int Depth) 
{ 

// Create a Width x Height popup window using the STATIC 
// control class so we don't have to implement a window 
// procedure right now 

Window = CreateUindowC'STATIC", "FullScreen", WS.POPUP, 
0, 0, Width, Height, 
0, 0, ghlnstance, 0); 
if (! Window) 
goto Failure; 

ShowUindow(Window, SU.SHOUNORHAL); 
UpdateWindow(Window) ; 

// Connect to DirectDraw, if not already connected 
if (! pDirectDraw) 

DirectDrawCreate(0, !ipDirectOraw , 0); 
if (! pDirectDraw) 
goto Failure; 

// Set up DirectDraw for full-screen exdusiie mode at the 
// requested resolution 
HRESULT DDReturn; 

DDReturn = pOirectDraw->SetCooperativeLevel(Window, 

DDSCL.EXCLUSIVE I DDSCL.FULLSCREEN) ; 
if (DDReturn != DO.OK) 
goto Failure; 

DDReturn = pOirectOraw->SetDisplayHode{Width, Height, Depth); 
if (DDReturn != DO.OK) 
goto Failure; 

// Create the primary surface 
// Try to get a triple-buffered one we can page flip 
PageFlip = 1; 

DOSURFACEDESC SurfaceDesc; 
ZeroKemory(&SurfaceDesc, sizeof (SurfaceDesc)); 
SurfaceDesc. dwSize = sizeof (SurfaceDesc); 
SurfaceDesc. dwFlags = DDSD.CAPS I DDSD_BACKBUFFERCOUNT; 
SurfaceDesc. dwBackBufferCount = 2; 
SurfaceOesc.ddsCaps.dwCaps = DDSCAPS.PRINARYSURFACE I 



DDSCAPS.FLIP I 

DDSCAPS.COHPLEX I 

DDSCAPS.VlDEONEnORY; 
DDReturn = pDirectDraw->CreateSurface(&SurfaceDesc, 

ftpPrimarySurface, 0); 
if (DDReturn != DD.OK) 
{ 

// We couldn't get a triple buffer, try a double-buffer 

SurfaceDesc. dwBackBufferCount = 1; 

DDReturn = pOirectDraw->CreateSurface(&SurfaceDesc, 

lipPrimarySurface, 0); 
if (DDReturn != DD.OK) 
{ 

// We couldn't get a page-flip-able surface at all. 
PageFlip = 0; 

// Just go for a no-frills primary surface 
SurfaceDesc. dwFlags = DDSD.CAPS; 
SurfaceDesc. dwBackBufferCount = 0; 
SurfaceOesc.ddsCaps.dwCaps = DDSCAPS.PRINARYSURFACE; 
DDReturn = pOirectDraw->CreateSurface(&SurfaceDesc, 

ftpPrijnarySurface, 0); 
if (DDReturn != DO.OK) 
goto Failure; 



} 



if (PageFlip) 
{ 

// Get the attached page-flip-able surface as the 
// offscreen buffer 
DOSCAPS caps; 

caps.dwCaps = DDSCAPS.BACKBUFFER; 
DDReturn = pPrimarySurface->GetAttachedSurface(!icaps, 
4p0f f screenSurf ace) ; 

} 

else 
{ 

// Create a second surface for the offscreen buffer 
2eroMemory(&SurfaceDesc, sizeof (SurfaceDesc)); 
SurfaceDesc. dwSize = sizeof (SurfaceDesc); 
SurfaceDesc. dwFlags = DDSD.CAPS I ODSD.HEIGHT I DOSD.WIOTH; 
SurfaceOesc.ddsCaps.dwCaps = DDSCAPS.OFFSCREENPLAIN; 
SurfaceOesc.dwWidth = Width; 
SurfaceDesc. dwHeight = Height; 

DDReturn = pOirectDraw->CreateSurface(ftSurfaceDesc, 
lipOffscreenSurface, 0); 



if (DDReturn != DD.OK) 
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Listing 1. (Continued from p. 46) 



goto Failure; 

^^^// Set up a palette - a grey wash in 0..255 

IPALETTEENTRV PaletteColors[256] ; 
int i; 
for (i=0; i<256; ++i) 
PaletteColors[i] .peRed = i; 
PaletteColors[i] .peGreen = i; 
PaletteColors[i] .peBlue = i; 
PaletteColors[i].peFlags = PC.RESERVED; 

DDReturn = pDirectDraii->CreatePalette(DDPCAPS.8BIT, 

PaletteColors, SipPalette, 0); 
if {DDReturn != DD.OK) 
goto Failure; 

// Attach the palette to the surface 
DDReturn = pPriiiiarySurface->SetPalette(pPalette); 
if (DDReturn != DD.OK) 
goto Failure; 

// Success! 
return 1; 



Failure: 
return 0; 

} 



cations to exert low- level control over 
display settings. 

D isplay M anager 1.0 now ships as 
part of System 7.5.1, but it sports a 
clunky programming interface and is not 
always reliable. Display M anager 2.0 is 
available as an extension for these systems 
and is integrated into System 7.5.2. It's 
cleaner and simpler, so we'll be writing 
for version 2.0. 

If you don't have Display M anager 
2.0, you can download it from Apple's ftp 
site, at ftp://ftp.info.apple.com/ 
A pple.Support.A rea/D eveloper_ Services/ 
D evelopment_K its/D isplay_M anager_ 
D evelopment_K it. 

Listing 2 shows the complete Begin- 
FuUScreen procedure for the M acintosh so 
you can sing along. 

The first step to taking over the M ac- 
intosh display is to get rid of that pesky 
menu bar. I 've written a StealHenuBar func- 



tion to recover the screen space used by 
the M acintosh menu bar. Once it's gone, 
we'll create a window of the requested size 
and set up a palette as I discussed in previ- 
ous articles. 

N ow the D isplay M anager comes into 
play. The first thing to do is to store away 
the current display settings so we can 
restore them when we're done harassing the 
video hardware. A call to GetMainDevice 
gives us a handle to the main display device, 
and DHGetDisplayMode fills US in on its cur- 
rent settings. 

n the M acintosh, a display mode is 
defined by two numbers: csMode and csData, 
which together describe a unique color for- 
mat, resolution, and refresh rate setting. In 
order to change the display mode, we have 
to find out the appropriate secret numbers 
for the mode we want. T he D isplay M an- 
ager will provide us with a list of available 
modes through DMNeuDisplayModeList, and 



we'll scan through that list until we find an 
appropriate one. 

DMGetlndexedDisplayModeFroitiList iter- 
ates through the list for us. You give this 
function a pointer to a callback function 
and a pointer to some data of your choice, 
and it invokes the callback on each element 
in the list. NeuDMDisplayModeListlteratorProc 
(whew!) creates a universal procedure 
pointer to use as your callback (this is simi- 
lar to the W inl6 HakeProcInstance func- 
tion). W e'll pass along a custom DispiayMode 
Request Structure that tells the callback what 
resolution to look for and includes space for 
it to return the csMode and csData codes if it 
finds the requested resolution. 

nee out of the loop, ModeRequest will 
contain valid information if the Display 
M anager reported a mode we can use. I f so, 
DMSetDisplayMode will make the switch for 
us 

Finally, we can create an offscreen 
GWorld for the window as we did before, and 
we have total double-buffered control at the 
desired resolution. 

Offscreen Access 

A few more functions round out our full- 
screen needs. EndFullScreen will undo every- 
thing done by BeginFunScreen. SuapBuffer 
will either copy or page flip the offscreen 
buffer onto the screen. SuapRect will copy a 
portion of the offscreen buffer onto the 
screen. OffscreenLock and OffscreenUnlock 
will give us access to the bits of the off- 
screen image, and between these two calls, 
GetOffscreenBits and GetOffscreenStride 
will provide us with the information we 
need to draw on the surface. 

n the M acintosh, we don't have to 
learn anything new. Sure, we've used the 
D isplay M anager to tweak the monitor to 
the settings we want, but otherwise every- 
thing's fundamentally the same: we still 
have a window, a GWorid, and palette. W e'll 
still use CopyBits to get the GWorld to the 
screen, and we'll still lock and unlock the 
bits of the GWorld PixMap to gain access to 
the offscreen buffer, as I demonstrated 
before. 

U nder W indows, however, things 
have changed. No more DIBSections, no 
more W InG . W e're now cooking with 
DirectDraw surfaces, and they require 
some special handling. The OffscreenLock 
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Listing 2. Setting Up a Full-Screen Environment Using Display Manager 2.0 (Continued on p. 49) 




static UindowPtr Uindou; 
static PaletteHandle hPalette; 
static GUorldPtr pOffscreenGUorld; 
static GDHandle DisplayDei/ice; 
ft 

static unsigned short csPreviousHode; 
static unsigned long csPre«iousData; 



// This structure encapsulates the data sent to the Display Manager list 
// enumeration callback function. Ue fill in the desired »alues, pass 
// this on through the enumeration, and it fills in the csBode an 
// csData info we need, 
struct DisplayModeRequest 
{ 

// Returned values 
unsigned short csMode; 
unsigned long csData; 

// Provided values 
long DesiredUidth; 
long DesiredHeight; 
long DesiredDepth; 




}; 



^^^H pVPBlocklnfo 

^^^^1 pModelnfo->displayl'lodeDepthBlocklnfo-> 
^^^^^^^ depthVPBlock[Count] .depthVPBlock 

} 

int BeginFuUScreenCirt Width, int Height, int Depth) 
{ 

// Hide the menu bar 
StealHenuBarO; 



if {pl/PBlockInfo->vpPixelSize == 
pRequest->DesiredDepth U 
pVPBlockInfo->»pBounds. right == 
pRequest->DesiredUidth U 
pVPBlockInfo->vpBounds. bottom == 
pRequest->DesiredHeight) 

// Found a mode that matches the request! 
pRequest->csMode = pSuitchInfo->csMode; 
pRequest->csData = pSuitchInfo->csData; 



// This function filters through the display modes reported by the 
// Display Banager, looking for one that matches the requested 
// resolution. The userData pointer will point to a DisplayModeRequest 
// structure. 

pascal void DisplayHodeCallbackCvoid* userData, DMListlndexType, 
DMDisplaynodeListEntryPtr pHodelnfo) 

{ 

DisplayModeRequest *pRequest = (DisplayModeRequest*)userData 

// Get timing info and make sure this is an OK display mode 
VDTiminglnfoRec Ticninglnfo = *(pHodeInfo->displayModeTiiningInfo); 
if (Timinginf . csTimingFlags It l«kModeValid) 
{ 

// How many modes are being enumerated here? 
unsigned long DepthCount = 

pModeInfo->displayModeDepthBlockInfo->depthBlockCount; 

// Filter through each of the modes provided here 
VDSwitchlnfoRec *pSwitchInfo; 
VPBlock *pVPBlockInfo; 

for {short Count = 0; Count < DepthCount; ++Count) 
{ 

// This provides the csMode and csData information 
pSwitchlnfo = 

pModelnfo->displayModeDepthBlockInfo-> 
depthl/PBlock [Count] . depthSwitchInf o ; 

// This tells us the resolution and pixel depth 




// Create a window of the requested size 
Rect WindowRect = { 0, 0, Height, Uidth }; 
Window = NewCUindow(0, MindowRect, "\pFullScreen", 

TRUE, plainDBox, 

UindowPtrC-1) , FALSE, 0); 
if (! Window) 

goto Failure; 

// Set up a palette with a gray wash 
hPalette = NewPalette(256, 0, pmExplicit I pmUnimated, 0); 
if {! hPalette) 
goto Failure; 

RGBColor Color; 
int i; 

for (i=0; i<256; ++i) 
{ 

Color. red= i « B; 
Color. green = i « 8; 
Color. blue = i « 8; 



SetEntryColor(hPalette, i, &Color); 



} 



// Force and 255 to White and Black 
SetEntryUsage(hPalette, 0, 

pmExplicit I pmAnimated I pmUhite, 0); 
SetEntryUsage(hPalette, 265, 

pmExplicit I pmAnimated I pmBlack, 0); 
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Listing 2. (Continued from p. 48) 



SetPalette(Uindow, hPalette, TRUE); 

// Store information about the current display settings 
DisplayDevice = GetHainDe»ice(); 
if {!DisplayDe»ice) 
goto Failure; 

csPreviousWode = -1; 
csPreviousData = -1; 

VDSwitchlnfoRec Displaylnfo; 

OSErr MacError = DHGetDisplayHodeCDisplayDevice, &DisplayInfo); 
if (MacError != noErr) 
goto Failure; 

csPreviousHode = Displaylnfo. csHode; 
csPreviousData = Displaylnfo. csData; 

// Get the display ID for the main display 
DisplaylDType DisplaylD; 

DMGetDisplayIDByGDe»ice(DisplayDevice, MisplaylD, FALSE); 

// Use it to get a list of available modes from the 
// Display Manager 

DHListlndexType DisplayHodeCount = 0; 

DHListType Display HodeList; 

MacError = DHNeuDisplayHodeList(DisplayID, 0, 0, 

SiDisplayHodeCount, &DisplayHodeList) ; 
if (MacError != noErr) 

goto Failure; 

// Create a callback function pointer to filter available modes 
DMDisplayModeListlteratorUPP uppDisplayModeCallback = 

NewDMDisplayModeListlteratorProc(DisplayHodeCallback); 
if ( ! uppDisplayModeCallback) 



// Aborting - let go of the mode list 
DMDisposeList(DisplayModeList) ; 
goto Failure; 



for (short Count = 0; Count < DisplayModeCount; ++Count) 
{ 

DMGetIndexedDisplayModeFromList(DisplayModeList, Count, 
0, uppDisplayModeCallback, (void«)ModeRequest); 

} 

// Done with the list 
DMDisposeList(DisplayModeList) ; 

// Done with the callback 

DisposeRoutineDescriptor(uppDisplayHodeCallback); 

// If we found a mode fitting the request, switch to it! 
if (ModeRequest.csMode == -1 1 1 ModeRequest.csOata == -1) 
goto Failure; 

Displaylnfo. csMode = ModeRequest.csMode; 
Displaylnfo. csData = ModeRequest.csData; 

unsigned long Mode = Displaylnfo. csMode; 
MacError = DHSetDisplayHode(DisplayDevice, 

Displaylnfo. csData, SiMode, 

(unsigned long)&DisplayInfo, 

0); 

if (MacError != noErr) 
goto Failure; 

// Create a matching GUorld using current device and window 
CGrafPtr CurrentPort = (C«indowPtr)«indow; 

PixMapHandle CurrentPixHap = CurrentPort->portPixMap; 
CTabHandle ColorTable = (*CurrentPixMap)->pmTable; 

NewG«orld(4pDffscreenGUorld, (short)Depth, 

KurrentPort->portRect, ColorTable, 

DisplayDevice, noNewDevice); 
if (IpOffscreenGUorld) 

goto Failure; 

// Success! 
return 1; 



// Go through the list, comparing each available mode with 
// this mode request 
DisplayHodeRequest HodeRequest; 
ModeRequest.csMode = -1; 
ModeRequest.csData = -1; 
ModeRequest.DesiredUidth = Uidth; 
ModeRequest.DesiredHeight = Height; 
ModeRequest.DesiredOepth = Depth; 



Failure: 

RestoreMenuBarO; 
return 0; 

} 
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Listing 3. Loading a DirectDraw Surface 



static char unsigned *pBits; 
static long Stride; 

int OffscreenLock(void) 
{ 

int ReturnValue = 0; 

pBits = 0; 
Stride = 0; 

DOSURFACEDESC SurfaceDesc; 
ZeroHemorydiSurfaceDesc, sizeof (SurfaceDesc)) 
SurfaceDesc.duSize = sizeof (SurfaceDesc); 



Listing 4. A 640x480x8 Cross- Platform Demo 




and CffscreenUnlock functions just map 
onto calls to D IrectD raw's Lock and 
Unlock, but these may fail if the surface is 
busy. 

If an asynchronous bit or a flip has 
been started but hasn't finished, we'll 
receive a dderr.wasshlldrawing code from 
most DirectDraw functions, indicating 
that we have to wait until the hardware 
has completed its tasl<. If we receive a 
DDERR.SURFACELOST notification, Direct- 
Draw has given our video memory to 
someone else, and we have to restore all 



of our surfaces before we can use them 
again. Although this shouldn't happen 
when we've set ourselves to ddscl.exclu- 
SIVE, we should be ready for it. W e have 
to wait in a uhile(l) loop trying to lock 
the surface until we receive a dd.ok or a 
fatal error code. 

A similar situation occurs during a 
Flip, a Bit, or a BltFast call: it may be nec- 
essary to wait until the surface becomes 
available Passing DDFLIP.WACT, DDBLT.WAIT, 
or DDBLTFAST.WAir will force D IrectD raw to 
wait until the operation completes before 



returning, eliminating the possibility of 
contention, but that may waste time you 
could spend doing some other processing. 

L isting 3 shows the D irectD raw 
implementation of OffscreenLock. The 
other functions use a similar loop to wait 
until the operation succeeds, bailing out if 
an error occurs. 

This Month's Cheesy Denx> 

Of course, to prove this worl<s, I have to 
write a simple cross- platform program 
using these functions. Unfortunately, 
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there's no means of user input in this 
month's code, though by combining the 
full-screen code presented here with the 
message processing architecture in XSplat, 
you can easily build an interactive system. 

This month's demo has the simple 
goal of setting up a 640-by-480-by-8 
graphics environment and drawing palette 
washes for ten seconds, starting each wash 
with a different index. The resulting pat- 
tern will make you feel like your old black- 
and-white has lost vertical synch. The 
code is shown in Listing 4. If you're look- 
ing at this with a page-flipped D IrectD raw 
surface, you'll see how incredibly smooth 
page flipping can be 

T he GetHmisecondTime function was 
presented in my last article, if you're won- 
dering about that. It maps onto timeGet- 
Time on W indows and TickCount (or 
Microseconds) under M acO S. 

Thoughts and Warnings 

Before I return to my cage for the next 
couple of months, there are a few hairy 
details you should hear about before 
plunging in with this full-screen API. 
H ere's my laundry list of warnings: 
■ W hen you lock a D irectD raw surface, 
D irectD raw grabs the W inl6 lock, the 
semaphore that prevents reentrant exe- 
cution of 16-bit system code including 
G D I and USE R. This means that 
essential system components shut down 
as long as you have a locked surface If 
you attempt to step through code with a 
GUI debugger while a surface is locked, 
you will hang the system. 

• SetCooperatiueLeuel uses the contents of 
the GWL.USERDATA bytes of a window to 
store information used to restore the 
display state This means that the hwnd- 
to-CXSplatWindow mapping used in my 
previous articles can not coexist with 
D irectD raw. If you want to use this 
association technique, set cbWndExtra to 
sizeof(cxSpiatWindou*) when registering 
the "XSPLAT" window class and use 
instead of gwl.userdata when setting or 
retrieving the data. 

• n many banked display cards, D irect- 
D raw emulates direct video access using 
a virtual device driver called 
VFLATD.386, which maps video 
memory banks onto selectors and uses a 



page fault handler to switch video banks 
when you cross a boundary. Only one 
display memory bank can be active at 
any time, so if you write across one of 
these boundaries, the fault handler will 
thrash as it attempts to write to both 
pages at once This will hang your sys- 
tem. Using only 32-bit aligned writes 
will guarantee that you never write 
across one of these boundaries. 
• Because the SuapBuffer function may 
use flip instead of bit, there is no guar- 
antee of the contents of the offscreen 
buffer after a swap. After a flip, the 
buffer will contain the former contents 
of the display. After a bit, it will remain 
the same. If you need to preserve the 
contents of your offscreen buffer, always 

USeSuapRect instead of SuapBuffer. 
■ D irectD raw preserves color as black 
and color 255 as white. Changing the 
M acintosh display resolution and creat- 
ing a full-screen window doesn't cause 
the M ac to release colors (white) and 
255 (black) either, so the color zero 



problem remains. D on't forget! 

• W hen you shrink the resolution of the 
screen, D isplay M anager 2.0 will reposi- 
tion the open windows and icons on the 
desktop. W hen you set the resolution 
back, it may not replace them, leaving 
your desktop looking very strange 

■ The display mode you request through 
BeginFuUScreen may not be available. 
You can ask for a 100x609x13 display if 
you want, and BeginFuUScreen will try 
to accommodate you. A more robust 
system would provide a list of available 
modes rather than leaving you to cross 
your fingers, but do you expect a maga- 
zine article to do all your work for you? 
That's it! You can find the complete 

source code referenced in this article on 

the GameD a/eloper ftp site. ■ 

Jon Blossom sometimeswishes operating 
systems would go away so he could stop 
tweaking with M adntosh, Windows, OS/2, 
and X. H ecan bereadied at blossom@sllp.net 
or through G ame D eveloper magazine 
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Fuzzy Logic 
i n Games 




Figure 1. Trapezoids map precise variables sucli as temperature into linguistic variables such 
as "Warm." 
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Fuzzy logic is a powerful artificial 
intelligence (Al) technique 
appropriate in many gaming 
situations. The basic fuzzy 
technique is to specify a situa- 
tion using fuzzy linguistic vari- 
ables (FLVs), which, when 
cross-referenced on a fuzzy 
associative matrix (FA M ), create a "fuzzy 
set" on a third FLV. A fuzzy manifold 
can either be manipulated as its own type 
of object or it can be defuzzified into a 
more traditional crisp value. Similarly, 
crisp values can be fuzzified into FAM s 
If that jargon didn't explain it all, the 
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accompanying source code should make 
it concrete. 

A fuzzy linguistic variable is an 
array of labels such as "H ot," "W arm," 
"Cool," "Cold." Associated with this 
array is a mapping of a crisp values such 
as 68° F into the array. This mapping is 
done with trapezoidal membership defi- 
nitions, as illustrated in Figure 1. For 
each slot in the array, the logic designer 
chooses four numbers representing the 
begin low, full membership low, full 
membership high, and begin high values. 
L isting 1 shows a simple and quick func- 
tion for assigning a membership value to 
a value. 

As Figure 1 shows, a single crisp 
value can have some amount of member- 
ship in several slots in the FLV. For 
instance, the way I 've designed the room 
temperature manifold, 68° is an inflec- 
tion point, where the set changes from 
some membership in Cool as well as 
W arm to some membership in H ot as 
well as W arm. T he greater the overlap 
you put in your manifolds, the more 
continuous will be the fuzzy logic 
response curve— in effect, your critters 
will be less decisive. By decreasing the 
overlap, you can tune your A I for the 
opposite effect— more capriciousness. 
T his is the essence of fuzzy logic— mani- 
fold tuning, which can be done by a 
nonprogrammer on a spreadsheet, can 
create dazzlingly complex results. 

The complexity stems from the 
fuzzy associative matrix, a matrix in 
which two FLVs combine to specify 
membership in a third, as shown in Fig- 
ure 2. Adjusting the FAM provides gross 
adjustments in fuzzy logic, while mani- 
fold tuning provides the richness. A 



fuzzy system is simply one that sets up 
input FLVs and uses the resulting out- 
put FLV to specify behavior. 

Asa concrete example of the power 
of fuzzy logic, let's say you were working 
on a real-time strategy game of the 
C ommand & C onquer school. I t's usual- 
ly very difficult to get to work on the A I 
for such a game early in the design 
process, but fuzzy logic lets you do so. 
The A I designer can start with general 
rules such as, "D istance to the enemy 
and relative strength determine unit 
movement." After the rules have been 
determined, the FLVs associated with 
the antecedents (distance to the enemy 



and relative strength) and the conse- 
quent (movement) are roughed out. For 
simple purposes, you might choose, 
"Proximate," "Near," "Separated," and 
"F ar" as your distance FLVs "D ead 
Meat," "Overmatched," "Equal," 
"U ndermatched," and "Steamroller" for 
relative strengths, and "Run away," "Sur- 
render," "Retreat," "Fall Back," "Hold," 
"Probe," "Assault," and "Overrun" for 
movement. Behavior can then be 
roughed into a Fuzzy Associative 
M atrix, such as that shown in Figure 3. 

In a classical expert system or with 
naive state- based A I, the richness of this 
rule is severely reduced by the three- fold 




Figure 2. The two top fuzzy sets define the inputs to fuzzy output set at the bottom. Notice 
asymmetries introduced to make Al more aggressive. 
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Forget classical 
expert systems, 
Fuzzy logic makes 
your game Al subtle 
and complex, but it is 
easy to program an(j 
lightning fast at run- 
time, Here's a look at 
FLVs and FAMs, 

GAMEDEVELOPER -APRIL/MAY 1995 53 



FUZZY LOGIC 



W GAMES 



Listing 1. A Quick Function for Determining iVIembersiiip in a Trapezoidal Fuzzy Set 



dass FuzzySet{ 
public: 

float Meinbership(const floati inVal); 
private: 

float louHin, louTrue, highTrue, highMin; 
} 

float FuzzySet::HeiiiberShip(const float& inVal){ 
if (inVal > louMin Mi inVal < highnin){ 
if(inVal > louTrue){ 

ifCinVal < highTrue) { 

membership = 1.0; 

}else{ 

//must be on high edge 

membership = (inVal - louTrue) / (highMin - louTrue); 

} 

}else{ 

//must be on low edge 

membership = (inVal - louHin) / (louTrue - lowMin) ; 

} 

}else{ 

membership = 0.0; 

} 

return membership; 

); 




pigeonholing of crisp values. W e all 
l<now games where opponent behavior is 
clearly discontinuous— stand at one spot 
and the guards will ignore you, move 
another step closer and they start swarm- 
ing at you in their predictable manner. 
Fuzzy logic creates richer, continuous 
responses by evaluating all the rules, but 
gauging them on a spectrum ranging 
from totally false to totally true, with 
infinite gradations (rejecting the law of 
the excluded middle and the law of con- 
tradiction, for you fans of dead G reek 
mathematicians). Since it evaluates all 
the rules, the performance of a fuzzy 
logic inference engine degrades propor- 
tional to the total number of rules, and it 
is not subject to the catastrophic non- 
linear degradations that classical expert 
systems are prone to. 

After filling in the FAM and the 
FLV array for the fuzzy expert system, 
evaluation is the next step. Each cell in 
the FAM represents a rule so, for 
instance, the upper- left corner of the 
matrix in Figure 3 represents the fuzzy 
rule, "If the forces are engaged, and 
we're dead meat, surrender." To evaluate 
the rule, we determine the membership 
in the input FL Vs as described previous- 
ly and illustrated in Listing 1. While dis- 
tance is a crisp value, membership in the 
Relative Strength FLV is probably the 
result of another fuzzy rule. A ssume that 
membership in the "dead meat" FLV is 
28%. The degree of membership in the 
output is set equal to one of these two 
values— the minimum if the rule "and"s 
the antecedents, the maximum if the rule 
"or"s them. In this case, the rule is 
intended to be read "If the forces are 
engaged, and we're dead meat, surren- 
der," and not "If engaged or dead meat, 
surrender," so we set the membership in 
"surrender" for this rule to 28%. 

Since fuzzy logic allows various 
shades of truth, the entire rulebase is 
evaluated, setting various memberships 
in each of the output FLVs. For an 
"and" FAM , the maximums of the out- 
put values are chosen, if an "or" is cho- 
sen, the minimums are tal<en. A typical 
result is shown in F igure 4. T his output 
fuzzy set can be used as input to another 
rule or, if necessary, defuzzified by the 
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simple technique of calculating the cen- 
troid of the polygon. 

Fuzzy logic is an extraordinarily 
powerful and flexible artificial intelli- 
gence technique that is much easier to 
program than alternatives such as classi- 
cal expert systems. Unlike neural net- 
works, fuzzy logic systems can be tuned 
manually, and unlike genetic-based sys- 
tems, fuzzy systems work "out of the 
box." For continually improving perfor- 
mance, you can use machine-learning 
techniques to modify the parameters of 
the FLVs. Of course, "improved" is a 
fuzzy concept itself, and judging the effi- 
cacy of a move can be as hard or harder 
than making the move in the first place. 
Strategic analysis techniques, one of the 
oldest and deepest veins in the field of 
artificial intelligence, will have to wait 
for another day, however. ■ 

Editorial Director Larry O'Brien spe 
dalizesin artifidal forms of intelligence 
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CHOPPING BLOCK 



Bli 



rd of '96 



Mike Michaels 

secret to gaming 
success is getting 
users [looked on your 
game, Dscoverwhat 



tlie folks at Blizzard 



Entertainment did to 



make Ircraft II such 



an addictive game, 




icome to Chopping 
llock. In this issue, we'll 
pok at Warcraft II: Tides 
If Darkness, the sequel to 
Jast year's sleeper hit, W ar- 
:raft: res & H umans. 
IW arcraft 1 1 is a real-time 
[strategy war game with a 
fantasy theme. The object is to survive 
long enough to decimate all opposing 
forces and destroy all they hold dear. 

L ike its predecessor, the heart of the 
game is resource management. Before 
you can train your knights and archers, 
you must have a barracks to train them 
in. Before you can build a barracks, you 
must mine enough gold and harvest 
enough trees. Before you can mine gold 
and harvest trees, you must have peasants 
to do the work for you. H ow you allocate 
your limited resources can mean the dif- 
ference between victory and defeat. 



The game is played from an over- 
head, isometric viewpoint. Unlike other 
games in this genre, the viewpoint is 
close enough to the ground that both 
the buildings and the creatures are ren- 
dered with a high degree of detail. This 
propensity of detail stems from the 
game objects (creatures, buildings, ves- 
sels) being first modeled (using 3D Stu- 
dio or the like) and then rendered at the 
required sizes. The knights you control 
in the game are rendered from the same 
model used to generate the knights in 
the cut- scenes. 

The game is tile based, and all 
game objects are an integral number of 
tiles large. Don't make the mistake of 
assuming that the game looks blocky. 
The programmers did a wonderful job 
when they created their map editor. I 
won't venture a guess as to what algo- 
rithm they used to create their coast- 
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lines, but I was extremely impressed by 
how natural and asymmetric it all is. A 
creature can move without too much 
hint of tile transitions. bviously, 
enough frames of animation were pro- 
vided to mal<e the tile transitions seam- 
less. The only time you realize this 
underlying tile system is when a creature 
must go around another creature or 
object. W hen this occurs, the creature 
mal<es a 45- degree turn and moves to a 
diagonal tile. Then the creature finds 
the nearest tile it can move to that reori- 
ents it on its goal. The overall effect is 
that the creatures move in a very unnat- 
ural manner (angular rather than a more 
natural, circular path). 

The interface is very intuitive. You 
can control creatures using either the 
mouse or the l<eyboard (or a combina- 
tion of both). Simply clicl<ing the cursor 
on a creature selects that creature and 
brings up a series of buttons represent- 
ing actions the creature can perform. 
M oving the cursor over one of the but- 
tons brings up a description of the 
action and, if appropriate, the amount of 
resources that must be paid to perform 
the action. 

Distinguishing itself from it's pre- 
decessor, W arcraft II provides sea and 
air units along with shipyard and 
aviaries to train these units. The beauty 
of the interface is that there is essentially 
no difference between controlling a sol- 
dier and controlling a battleship. The 
same options are available for both. J ust 
choose an option and choose a target. 
It's that simple. 

W arcraft 1 1 lets players choose 
either single- player or multi player sce- 
narios. M ultiplayer support is available 
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In Bli::ard Entertainment's game, you 


strategize to survive. 



Warcraftllilides of Darkness 



Blizzard Entertainmeirt 
P.O. Box 18979 
Irvine, Calif. 92713 
Tel: (800) 953-7669 
Web: http://www.blizzard.com/ 
Price: $54.95 



via null modem, modem, and IPX net- 
work. W ith a networl< connection, up to 
eight simultaneous players are possible, 
including computer opponents. 

I didn't get a chance to try the 
direct connect or modem options, but I 
can attest that the game plays smoothly 
over a standard IPX network. I installed 
it at work on two Pentium machines 
running W indows95 with standard net- 
work support. No extra effort was 
required, the game picked up connec- 
tion immediately, and the speed of game 
play seemed to be identical to that of 
single-player mode. 

If you choose to play the single- 
player game, fourteen human and four- 
teen ore campaigns are provided. Things 
don't really start getting difficult until 
around the sixth or seventh campaign, at 
which point they get very challenging. 
Unfortunately, this challenge isn't really 
due to increasing the game's artificial 
intelligence (A I). Rather, the challenge 
comes from increasing the amount of 
resources your enemy starts the scenario 
with. It can be a little discouraging to be 
attacked by dragons when you can't even 
build flying units yet. 

But other than the numerical 
advantage, the computer opponent 
doesn't appear to cheat. It seems to be 
following the exact same rules you have 
to follow. n the other hand, the A I 
doesn't appear to be particularly smart 
either. There doesn't appear to be an 
overriding intelligence in the computer 
opponent. Asa human player, I jump 
around the map keeping track of what 
is going on in many sectors of the game 
at once. The computer artificial intelli- 
gence doesn't have this advantage. In 
general, it looks like each creature has 
its own A I routine to determine what 
its next action should be. W ith no 



System Requirements: 486DX/33, 
8MB RAM, 29MB free hard-drive space, 
SVGA graphics, Sound Card (Redbook 
Audio, General Midi, Sound Blaster, PAS, 
Gravis, and compatibles), and a double- 
speed CD-ROM drive. 



omniscient intelligence, the computer 
opponent makes the same mistakes 
repeatedly. 

For example, assume there is a gold 
mine out of visual range for any of the 
enemy's fighting units. You can sit a few 
soldiers and archers around the mine 
and pick off enemy peons as they come 
to mine the gold. If this happened to a 
human player, units would be dis- 
patched almost immediately to get rid of 
the troublemakers screwing up the gold 
supply. The computer opponent doesn't 
seem to notice that the peons it is send- 
ing to collect gold never seem to return. 

The map editor is included with 
the game so that you can create your 
own scenarios. The map editor requires 
Windows 95 to execute. Building maps 
is a snap. It's as simple as selecting an 
object and clicking on the map screen. 
There's even an animate feature that will 
let you give your scenario a test run. 

L ike it's predecessor, W arcraft 1 1 is 
extremely addictive. The graphics are 
vibrant; the sound is great (hilarious at 
times); and the ability to play the game 
against many opponents makes this a 
sure bet at bringing the office network 
to a standstill. 

That's it for this month. I'm still 
interested in hearing your opinions 
about the direction that you'd like to see 
this column progress. If you have any 
idea's or opinions, just drop me an e- 
mail at the address provided below! ■ 



M ike M idiaels is doubtful that any- 
one reads these little bios (unless they're 
lookingfor hise-mail address to flame him) 
and therefore chose not to write one this 
month. H e may be reached via e-mail at 
mike@irvine.com or through Game 
D eveloper magazine 
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VN/liere -the Sun 
Don't Shine 



David Sieks 



Lighting is vital to 
making your 3D games 



look realistic, Sieks 



takes us through the 
ins and outs of hard 
and soft lighting- 
learn how to really set 



the mood, 



Game graphics used to be easy: 
you'd put row after row of 
blocky space aliens at the top 
of the screen and a clunl<y 
ppace cannon at the bottom 
pf the screen, all against a 
black background (because, 
did I mention, this takes 
place in space) and ta-dah...you got 
game graphics. At this level, graphics 
could routinely be handled by the pro- 
grammers themselves— no need to 
involve an artist. 

N ow, of course, it is a different 
matter. T he visual component seems to 
have taken precedence over game play 
and originality. (H ey, that's not my beef: 
this is the Artist's View, man.) The 
market demands that games of all gen- 
res look as good as they can get, which 
provides plenty of opportunity and chal- 
lenge for talented artists. 

Even relatively straight-ahead 
shooters have gorgeous, rendered back- 



grounds; it's all but mandatory to include 
cinematic intros and cut sequences in 
everything from flight sims to fight- 
fests. Since the coming of M yst, adven- 
ture games must (it is a law) try to outdo 
one another in visual atmosphere. W hen 
you try to make eye- popping visuals at 
this demanding level, when your task is 
to capture an audience's interest and spur 
its imagination, you need to make use of 
every tool at your disposal. 

Artists working with three-dimen- 
sional graphics now need to acknowledge 
something that photographers and cine- 
matographers have held as a central tenet 
of their art forms throughout the century 
and that realist painters have practiced 
for longer still: control of a scene's light- 
ing determines much of its impact. One 
cannot discern color or form without illu- 
mination, but, in the context of a scene, 
lighting takes on added significance. 
Used judiciously, areas of light and dark 
create the overall composition, direct the 





g flashlight beam heightens the creep 
est, from Virgin Entertainment and Trilobyte Inc. 
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audience's attention, and can worl< to cue 
expectations in the viewer and to under- 
score the narrative. 

Yes, 3D artists should realize the 
importance of lighting. It is all too easy 
to focus on the obvious challenges of 
modeling, texture mapping, and anima- 
tion and pay only perfunctory notice to 



Me are two 
basic approaches 
to lighting a 
scene: the realistic 
and the expres- 
sionistic,or,to 
throw out a real 
film- weenie term, 
the diegetic and 
the nondiegetic, 



the demands of lighting a scene whose 
other components we have worl<ed on 
so painstal<ingly. To do justice to every 
element, you need to spend equal time 
on and pay equal attention to each. A 
careless approach to lighting, however, 
can negate much of the hard worl< put 
into every other aspect by creating a 
flat, dull scene— or one that lool<s 
instantly and unmistal<ably computer 
generated. 



Effect over Fact 

W hen tacl<ling the task of lighting a 
scene, one must thinl< in terms of con- 
trast—that is, the juxtaposition of light 
and darl<. The effect is the important 
thing: not how many lights you place or 
where or what the logical source of such 
illumination would be, just how it all 
looks. A common pitfall is to create 
lights in the 3D scene that are, as nearly 
as possible, strictly analogous to the real- 
world light sources. Unfortunately, in 
the realm of 3D graphics, good lighting 
isn't as easy as flicking a switch. 

First, the particular characteristics 
of computer graphics lights usually make 
it necessary to work with placement, 
intensity, and so on to finagle the desired 
effect. For example, you might need to 
place additional lights to simulate the 
effects of radiosity (the dispersal and 
propagation of reflected light). Or you 
might need to situate a light somewhere 
other than its apparent source in the 
scene: for example, positioning a light 
outside the dimensional model of the 
light fixture to avoid an unwanted hot 
spot (a bright, central highlight) on a 
nearby surface. The guiding precept 
should be to forget about what makes 
strict sense and place the light where it 
gives the best effect. Artists are only 
constrained by reality on rent day. 

D espite the fact that they are cap- 
turing images of the real world, photog- 
raphers and cinematographers (who are 
also rent-paying artists) go to great 
lengths to achieve the lighting effects 
they want. Even when the end result is 
intended to be perceived as realistic, they 
make use of multiple lights, reflectors, 
diffusers, filters, and so on. As Anthony 
Burgess notes in A Clod<work Orange, the 
colors of the real world never look so real 
as on the screen. 

Pick a Palette of Light 

T here are two basic approaches to light- 
ing a scene: the realistic and the expres- 
sionistic, or, to throw out a real film- 
weenie term, the diegetic and the 
nondiegetic. D iegesis refers to the narra- 
tive, so diegetic lighting is that which, 
for the most part, seems consistent with 
the setting and the action of the narra- 



tive. Subtle finagling with additional 
lights, diffusers, reflectors, and filters (or 
their computer graphics counterparts) 
still falls within this first category as long 
as a convincing look is the intent. 

n the other hand, expressionistic, 
nondiegetic lighting is that which 
throws all pretense of realism out the 
window (at least for the moment) and 
goes purely for effect, using sometimes 
subliminal, psychological connotations 
of light, shadow, and color to make its 
point: bathing a scene of violence in red 
light or shining a heavenly light from 
above on a redeemed character. 
Nondiegetic lighting can tend to be 
cliched and even campy, but, used with 
restraint, can also be very effective in 
getting a point across quickly and sure- 
ly, as most people in your audience will 
intuit the intended meaning. 

Two basic ways of applying light to 
a scene exist: hard and soft lighting. 
H ard lighting refers to sharply defined 
areas of light and shadow, whereas soft 
lighting uses a more diffused light, with 
gentler shadows and blended areas. 

Though you may not have thought 
about it in such, well, black and white 
terms before, it's easy to see how hard 
and soft lighting fit into the basic light- 
ing styles and how they relate to the dif- 
ferent moods or genres commonly asso- 
ciated with them. Low-key lighting, 
often used for scenes of mystery or sus- 
pense, makes use of moody, atmospheric 
pools of light and dark. H igh-key light- 
ing is bright but not harsh, even illumi- 
nation with minimal shadows, generally 
used for lighthearted subjects. And high- 
contrast lighting juxtaposes dramatic 
streaks of light and shadow for a stark, 
edgy look full of tension. 

T hese lighting conventions are not 
ironclad rules. Of course, you don't 
have to use high-key lighting for a 
lighthearted scene. They are, however, 
conventions that come with baggage we 
have carried for millennia: our ancestral 
memory tells us shadows are frighten- 
ing; you'd better be prepared to work 
around that if you're determined to use 
low-key lighting in the splash scene for 
The Frolicsome Pony's Interactive 
Learning Adventure For Ages 6 to 9. 
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Can't Tell the Players 
Without a Program 

T he hump, of course, is figuring out how 
to control the lighting of a scene to use 
contrast knowingly and to your advan- 
tage. T hough computer artists have many 
challenges unique to our medium, we can 
still learn much by observing the tradi- 
tional approaches to lighting practiced by 
film artists. T here we find not only a 
long, practical experience with the topic, 
but an established professional jargon that 
facilitates its discussion. 

The classic H ollywood approach to 
lighting generally involves at least three 
light sources— namely the key light, fill 
light, and backlight. Of primary impor- 
tance among one's lighting tools is the 
key light. T his is the chief light source 
for the scene and casts the dominant 
shadows. A fill light is then used to "fill 
in" or soften shadows created by the key, 
while the backlight serves to separate the 
figure from the background. Typically, 
each major character (or other object of 
focus) will be assigned a key, fill, and 
backlight, though often one light can 
serve more than one figure. 

T he purpose of lights is to define 
form by painting the figure with light 
and shadow. T o that end, the key light is 
generally positioned so its rays strike the 
figure diagonally from the front, near but 
off to one side and typically higher than 
the camera; this is known as "modeling 
light" because it tends to model the form 
well and be the most flattering. M ore 
direct, frontal lighting is to be avoided, 
as it will work to minimize shadows and 
thus flatten the appearance of form. A 
"skim" or "raking" light is a key light 
that comes from an oblique angle to the 
viewpoint; that is, one set more to the 
side than at a diagonal. It creates strong, 
long shadows and is useful for capturing 
surface detail. The key light will be the 
brightest in the scene and should be 
placed first. 

T ry a test render with just the key 
light in place. Next, place a fill light to 
soften and deepen the shadows cast by 
the key. The fill light should be lower 
than the key in intensity and is also often 
positioned lower in the scene, to light 
the figure from slightly underneath. Or, 



sometimes fill light is set to gently illu- 
minate a portion of the background to 
diminish a cast shadow. 

One great advantage computer 
artists have over film artists is their abili- 
ty to use shadow casting selectively. All 
3D programs seem to have some provi- 
sion for turning shadows on or off, so 
that either a light doesn't cast them or an 
object doesn't receive them. Take advan- 
tage of this ability. A fill light that soft- 
ens existing shadows without adding 
more shadows to the scene can be a great 
tool. Just because a real-world light 
would cast shadows doesn't mean every 
light in your 3D scene hasto. 

A kicker or backlight— also known 
as a rim or separation light— provides 
depth cues by separating the figure from 
the background. T he intensity of illumi- 
nation should fall between the key light 
and the fill lights. If there is not suffi- 
cient difference in the intensities of these 
lights, the tonal variations will not work 
well to suggest form, and the result will 
be a flatter, less dimensional look. Back- 
lighting works best when directed from 
above and, obviously, behind the figure. 
It can be more or less to one side or the 
other as preferred. 

At this point in your lighting setup, 
it is a good idea to balance the intensity 
levels of these main lights to achieve ade- 
quate illumination for the scene, remem- 
bering that to get a good tonal range the 



lights should decrease in brightness from 
key light to backlight to fill light. D o test 
renders and change light levels till the 
overall brightness and mix of light and 
dark is to your liking. You have "roughed 
out the canvas," so to speak. N ow look at 
the scene with an ^e to detail and really 
begin to paint with light. 

See Spot Shine 

T he spotlight is the lighting technician's 
sable hair brush. Spotlights can be accu- 
rately aimed to illuminate objects or 
areas, to highlight details and direct the 
audience's attention. (3D Studio lets you 
place a highlight where you want, then it 
positions the source light accordingly.) 
ne characteristic of spotlights is falloff: 
the extent to which the light diminishes 
in intensity away from the center of the 
beam. A light with little or no falloff 
appears as a sharply defined circle 
(assuming a circular spot), where a light 
with greater falloff has less distinct edges 
with a brighter center: the hot spot. A 
tightly focused spotlight that highlights 
a very specific area is known as an accent 
light. A spot aimed so the hot spot 
"misses" the figure— thus achieving a less 
intense highlight on the subject itself— is 
called a feathered light. 

You can use multiple spots of vary- 
ing size and falloff to highlight and 
brighten key features, but be aware of 
the amount of illumination you add to 
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fields, atmospheric iigliting effects set 
tlie mood in Buried In Time, by 
Sanctuary Woods and Presto Studios. 



the scene. As you add more lights to 
your scene, you'll want to adjust the 
intensity levels of existing lights so you 
don't wash out details by over- illuminat- 
ing them. Avoid overwhelming the scene 
with shadows that come from all direc- 
tions because of the myriad lights set 
about. For most accenting purposes, 
spotlights can best be set to cast light 
without shadows. 

One interesting lighting tool com- 
puter artists have over film artists is the 
darkon, a light with a negative intensity 
value. By setting the intensity level 
below zero, the darl<on's rays in fact 
remove light color from areas they con- 
tact. In addition to a darl<ening effect, 
the darl<on can force a color shift in the 
affected area. W hat it's doing is sucking 
light color from everything it touches in 
the scene, but doing so selectively. E ven 
white light is composed of RG B values 
(translated to hue, luminance, and satu- 
ration or H LS values); by removing 
more of the red channel, for example, 
the darkon can cause the remaining 
light to appear greenish. It's a neat spe- 
cial effect, but it can be tricky to con- 
trol. If the darkon is neutral in color- 
that is, has a zero saturation setting— it 
reduces the RG B color channels evenly 
and has a darkening effecting without 
changing color. 

Imitating Mother Nature 

Effective use of light and shadow not 
only helps the look of a scene, it can 
contribute to its narrative strength 
while saving the artist time and effort. 
A very useful tool toward this end is a 



2D transparency map used as a gobo. A 
gobo is a screen that blocks light— or, 
more usefully, partially blocks light. In 
computer graphics terms, the gobo is 
used as a projection light: the opaque 
areas cast shadows on the scene. W ith a 
gobo, it's easy to create the appearance 
of shadows cast by offstage objects. You 
can create the effect of dappled sunlight 
through a forest canopy without having 
to model a forest full of trees or suggest 



a jail cell with the stripey shadows of 
cell bars. 

Your gobo can be animated, too, 
which adds even more detail and depth 
to the scene with minimal effort: it can 
be much easier to create a 2D animation 
in silhouette than to model and animate 
a comparable scene in 3D. A 3D pro- 
gram that doesn't have projection lights 
per se but that does have raytracing 
capability can still make use of the gobo 
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technique by painting a planar object 
with the transparency map and position- 
ing it in front of the light source so that 
it casts the desired shadow. 

The gobo technique can also be 
used with subtler grey scale or color gra- 
dations as a computer graphics analog to 
the photographer's diffuser to soften the 
effect of a light or breal< up the evenness 
of its illumination. This results in a less 
rigid, more natural appearance. W hen 
striving for realistic lighting effects— 
especially for outdoor lighting— don't be 
constrained by the limits of the computer 
screen. T he closer lights are positioned to 
the objects in a scene, the more apparent 
the effect of falloff will be, and the more 
flare any cast shadows will display. 

Because of its great distance from 
the Earth, sunlight produces both an 
even illumination and shadows we per- 
ceive as running parallel. Simulate this 
by placing "sun" light sources at a dis- 
tance from your scene. A Iso for simulat- 



ed sunlight, avoid using attenuated light 
levels— those that diminish with dis- 
tance from the source— with the possible 
exception of a sunset effect. 

What Do They Expect? 

W ith these tools in your arsenal, you can 
use light and shadow to greater effect in 
your scenes. Beyond making an image 
look good, lighting gives you the oppor- 
tunity to play on the psychological con- 
notations with which dark and light are 
freighted. T here are pretty clearly under- 
standable reasons why our primitive 
ancestors feared the darkness, which 
have only been reinforced by the symbol- 
ic use of light and dark through the ages. 
I n darkness lurks all that is unknown and 
unsafe— dread, evil, death. By dispelling 
darkness, light promises truth, brings 
reassurance, and suggests virtue, happi- 
ness, safety. 

Likewise, lighting color has signif- 
icance as well. Orangey-red lights sug- 



gest fire, violence, or danger, while yel- 
low light is warm and welcoming. 
Bluish light can be morbid and is good 
for suggesting nocturnal scenes. Green- 
ish hues seem unnatural and are just 
plain creepy. Feathered accent hits of 
colored lights in an outwardly natural 
looking lighting scheme can add a nice 
undercurrent of implied meaning to 
your scene. 

Of course, these expectations can 
be played with, too. You can build ten- 
sion in the shadows without fulfilling it, 
and you can rain horror down upon 
your scene from a clear blue sky. The 
point is that, used knowingly, lighting 
effects can set your audience up just 
where you want them; what you hit 
them with is up to you. ■ 

D ave Sieks is a ODntri bating editor to 
Game Developer. You can contact via e- 
mail at 103302.301@compuserve.com or 
through G ame D eveloper magazine 
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